bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relo


From: i at maskray dot me
Subject: [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
Date: Wed, 13 Sep 2023 06:19:01 +0000

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.zejmknzcm5mwzzcz@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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]