https://sourceware.org/bugzilla/show_bug.cgi?id=30844
--- Comment #2 from Fangrui Song <i at maskray dot me> --- (In reply to Palmer Dabbelt from comment #1) > Nelson and I are just chatting about this. It's not intentional, but we > also don't quite know what the right answer is here: there's some relocs we > can touch less (like leaving R_RISCV_ALIGN in outputs even after we've > aligned, for example) but others we'd have to avoid relaxing (like > R_RISCV_CALL, which requires two instructions). Certainly producing > binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't > be producing binaries with it. > > So I think we're happy to fix bugs here, but we really need to know what the > desired output is. > > Do you have something more concrete about what you're looking for? Thanks for looking into this. My feeling is that --emit-relocs should switch to preserve the original relocation type, including R_RISCV_CALL_PLT(etc), R_RISCV_RELAX, and R_RISCV_ALIGN. Analysis tools can check whether R_RISCV_RELAX is present in a section. If present, they need to do disassembly work to figure out whether a R_RISCV_CALL_PLT relocations is associated with an un-relaxed code sequence of a relaxed code sequence. Yes, it may look dirty but I don't think there is a better way. (x86-32 relocation handling inspects the relocated relocation as well) FWIW I left a comment on https://lore.kernel.org/linux-riscv/20230912233331.zejmknzcm5mwz...@google.com/T/#t on the only --emit-relocs use I can find, which is relatively new in the Linux kernel. -- You are receiving this mail because: You are on the CC list for the bug.
