Electronics > Microcontrollers
RISC-V compilation errors - mismatched libgcc?
HwAoRrDk:
I am attempting to forge my own path in setting up a build environment for WCH CH32V003 RISC-V chips - that is, not using WCH's MounRiver or anything that comes with it. What I am using is the xPack RISC-V GCC distribution for Windows (specifically, xpack-riscv-none-elf-gcc-12.2.0).
But, I've hit a bit of a roadblock. :( When attempting to compile some code that does integer multiplication (e.g. something as simple as a = b * c), I'm getting a linking error:
--- Code: ---ld.exe: error: ../lib/gcc/riscv-none-elf/12.2.0\libgcc.a(muldi3.o): mis-matched ISA string to merge 'i' and 'e'
ld.exe: failed to merge target specific data of file ../lib/gcc/riscv-none-elf/12.2.0\libgcc.a(muldi3.o)
--- End code ---
What I'm wondering is, because the error message mentions "mis-matched ISA", is there somehow a mis-match in the architecture of my code and that of the libgcc it's trying to link? That is, GCC is using the wrong libgcc? If I go digging in the folder path that it gives for libgcc.a, I notice that particular library file seems to be a 'generic' one, and not one of the architecture-specific versions (e.g. 'rv32e', 'rv32i', etc.) residing in sub-folders. What also is of note is that there isn't one in existence for the architecture I'm specifying when compiling. So, is that why it's falling back to a 'generic' library?
The command line options I'm compiling with are:
--- Code: ---riscv-none-elf-gcc.exe -mabi=ilp32e -march=rv32ec_zicsr -msave-restore -misa-spec=2.2 -fdata-sections -ffunction-sections -fsigned-char -g -c main.c -o obj\Debug\main.o
--- End code ---
As mentioned above, there isn't a libgcc for 'rv32ec_zicsr', but there is one for 'rv32ec'. What will changing to the latter affect? What am I gaining or losing with or without the Zicsr (Control and Status Register) extension?
Also, on a related note, the QingKeV2 CPU manual from WCH says that it also features the 'XW' extension, but that appears to be non-standard. I'm guessing that's only available with the version of GCC they bundle with the MounRiver IDE? Seems like it just provides some extra 'compressed' versions of some instructions ("c.lbu/c.lhu/c.sb/c.sh/c.lbusp/c.lhusp/c.sbsp/c.shsp"), so the only impact would be on code size, right?
brucehoult:
It's unsurprising that a generic gcc package doesn't include RV32EC/ILP32E libraries, as the CH32V003 is probably the only chip in existence implementing RV32E.
Fair enough not wanting to use the MounRiver stuff, but I think you'll have to build your own libraries.
It's easy to build your own toolchain from https://github.com/riscv-collab/riscv-gnu-toolchain, either specifying a single arch and ISA, or following the "Build with customized multi-lib configure" section.
--- Quote ---Seems like it just provides some extra 'compressed' versions of some instructions ("c.lbu/c.lhu/c.sb/c.sh/c.lbusp/c.lhusp/c.sbsp/c.shsp"), so the only impact would be on code size, right?
--- End quote ---
Note that a number of those are in a standard extension that should be ratified maybe in July. I have no idea whether the opcodes are compatible!
Also, there is WCH's fast interrupt hardware register saving feature. Assuming you poke the right CSRs to enable that, you can use it from a standard toolchain by declaring your interrupt handler as __attribute__((naked)) (no function prolog or epilog .. no register saving/restoring, no "ret") and putting an inline asm "mret" at the end.
GromBeestje:
I have experienced similar problems,
The problem lies the linker doesn't recognise "-march=rv32ec_zicsr" means it should link the "rv32ec" libraries.
The solution would be to replace "-march=rv32ec_zicsr" with "-misa-spec=2.2 -march=rv32ec".
Using the ISA specs version 2.2, means before _zicsr was split off, and thus it should still be able to compile the code,
while the architecture is now set to rv32ec, causing the right libraries to be linked in.
Edit: I see you already got isa spec 2.2, then you could just use -march-rv32ec I guess
Anyways, building with "-march=rv32ec_zicsr" and linking with "--march=rv32ec" will work
HwAoRrDk:
--- Quote from: GromBeestje on February 15, 2023, 09:57:52 am ---Using the ISA specs version 2.2, means before _zicsr was split off
--- End quote ---
Ah, so later versions of the spec include Zicsr in the RV32EC specification by default? I only thought to include the -misa-spec=2.2 because the QingKeV2 CPU manual specifically says it implements v2.2.
I'm a bit confused about the ISA specification versions actually. GCC only takes three possible options for the 'isa' option: 20190608, 20191213, 2.2 (with the middle being default). Which is the latest/earliest?
--- Quote from: GromBeestje on February 15, 2023, 09:57:52 am ---Anyways, building with "-march=rv32ec_zicsr" and linking with "--march=rv32ec" will work
--- End quote ---
This turned out to be the solution. In actual fact, I realised I did not have any 'arch' or 'abi' options being passed at the linking stage at all! I needed to pass both -march=rv32ec and -mabi=ilp32e on the linker command line. The -misa-spec=2.2 option seemed not to be necessary or relevant to the linker. Confirmed in the .map file that it is now showing it is linking in rv32ec/ilp32e/libgcc.a(muldi3.o). :-+
--- Quote from: brucehoult on February 15, 2023, 09:37:29 am ---Also, there is WCH's fast interrupt hardware register saving feature. Assuming you poke the right CSRs to enable that, you can use it from a standard toolchain by declaring your interrupt handler as __attribute__((naked)) (no function prolog or epilog .. no register saving/restoring, no "ret") and putting an inline asm "mret" at the end.
--- End quote ---
Thanks, I will bear that in mind.
GromBeestje:
In another thread were I was talking about some debugging issues on riscv (turns out generating assembly listing generates broken DWARF)
The _zicsr / isa 2.2 was discussed on the rv32i rather then the rv32e. But I suppose the zicsr part is the same.
https://www.eevblog.com/forum/microcontrollers/risc-v-compiling-and-debugging/msg4682741/#msg4682741
Navigation
[0] Message Index
[#] Next page
Go to full version