-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rv32ec_zicsr tries to link against RVI libc #17
Comments
Thank you for the link, but can you summarise the issue? The current build uses the following multilibs: riscv-none-elf-gcc-xpack/scripts/versioning.sh Lines 61 to 119 in 2fd6aea
Do you imply that these definitions are incomplete/incorrect? |
The list doesn't contain _zicsr extension, but Zicsr ext will be useless here and I belive that it should't be added to the permutation set. In this case compiler should pull in the biggest common denominator being here is log when trying
|
Sorry but I'm no longer involved in the RISC-V development, and I don't know which are the valid combinations, I use only common 32/64 builds for my tests. The current list was inherited from previous releases, without a thorough analyse. If you know of a distribution that has a more up to date list, I can make a new release, but otherwise I don't know how to fix your problem. :-( |
did more tests and it seems that when there is no match for march string then it defaults to RV32GC libc e.g. RV32I_Zba pulls in RV32GC, RV32IC_Zba gives a false positive of compiling without any issues until A or M instruction is hit.
increasing permutation set for useless things like |
Please note that the xPack distribution uses the upstream sources, since SiFive no longer makes their toolchain public. |
@TommyMurphyTM1234, any comments on this issue? |
Sorry, not at the moment. I'll need to try to recap on the latest state of play with regard to multilib generation, reuse, and canonicalised versus non-canonicalised architecture strings. All of which have caused me no end of confusion and which cause problems with building and/or using the toolchain (https://github.com/riscv-collab/riscv-gnu-toolchain) lately. |
See my comments here: |
This issue/discussion might also be relevant here. |
This is a bit too confusing for me. :-( Do I have to adjust something in the multilib definition in my scripts? |
For me too! :-|
I'm not sure.
|
And we haven't even touched on proprietary extensions here yet! :-D |
That was the initial plan, but it is not realistic to add check buttons for all new extensions. I was even contemplating to remove all buttons and keep only the string field to enter whatever necessary.
You mean to make it include Zicsr? Now they are (in application.sh):
How would those two options look like? As for the long list of multiIibs, if you know how to make them accept more useful cases without increasing the length of the list, I can consider it. For example why not add Zicsr and Zifencei to all libraries? |
Yes - on the basis that, as far as I know and have experienced, most or all RISC-V targets will require CSR access instructions in practice. But, as ever, there is no "correct" answer here.
Presumably
I think that the GCC 13 changes mean that where a multilib for a specific
I don't know the answer to this question. |
whenever
-march=rv32ec_zicsr -mabi=ilp32e
is used any reference to standard lib (newlib nano specs) ends up with:The only working (with csr insns) workaround is to use
-march=rv32ec -mabi=ilp32e -misa-spec=2.2
(https://www.eevblog.com/forum/microcontrollers/risc-v-compilation-errors-mismatched-libgcc/)The text was updated successfully, but these errors were encountered: