multilib: use cmodel=medany when multilib is enabled #58
Conversation
This change mitigates a number of linker errors due to unsupported relocation types when multilib is enabled. A typical error would be of the form: ``` relocation truncated to fit: R_RISCV_HI20 against `.LC0' ``` There are a number of similar issues filed, but that example comes from riscv-collab/riscv-gnu-toolchain#784. In particular, this change allowed me to build the Zephyr RTOS for riscv with `CONFIG_NEWLIB_LIBC=y` without any such linker errors. Fixes riscv-software-src#57 Signed-off-by: Christopher Friedt <[email protected]>
|
Is the homebrew recipe really the right place for this? If this change is indeed appropriate (not saying it is--I think others might gripe), then I think it belongs in https://github.com/riscv/riscv-gnu-toolchain, since it's not specific to homebrew. |
|
@aswaterman any resolution on making this change elsewhere? Any harm in making it here? |
|
Well, I’m still not sure it is the right fix. Fundamentally, enabling multilibs and changing the default code model have nothing to do with each other. The only thing that should govern the choice of medlow (default) vs medany is the address at which code is linked. I guess it’s reasonable to resolve this issue here, but decouple it from multilib (i.e. make the change unconditional). We might give up <1% perf on some compiled code, but the package will work for more people out of the box. (Alternative is to expose the code model as an orthogonal option.) |
This does the right thing for more people's memory maps. It will result in a very slight perf regression in programs heavy in global variable access. For application code, the old behavior can be obtained by explicitly passing -mcmodel=medlow. Supersedes #58
This does the right thing for more people's memory maps. It will result in a very slight perf regression in programs heavy in global variable access. For application code, the old behavior can be obtained by explicitly passing -mcmodel=medlow. Supersedes #58
|
I merged #59 which should fix this. Thank you both for looking into this! |
This change mitigates a number of linker errors due to unsupported
relocation types when multilib is enabled.
A typical error would be of the form:
There are a number of similar issues filed, but that
example comes from riscv-collab/riscv-gnu-toolchain#784.
In particular, this change allowed me to build the Zephyr
RTOS for riscv on macos with
CONFIG_NEWLIB_LIBC=ywithout anysuch linker errors.
Fixes #57