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

[palmer at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30844

--- Comment #3 from Palmer Dabbelt <palmer at gcc dot gnu.org> ---
(In reply to Fangrui Song from comment #2)
> (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.

So we leave the R_RISCV_ALIGN in there and delete the excess bytes until it's
aligned?  That will result in a subtly different meaning for the output binary,
as the alignment will be smaller.  Maybe that's fine as the actual target will
already be aligned to the originally correct amount, but if something's trying
to then do more relaxation after we might have subtle issues.

> 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)

Ya, that's ugly -- but if it's the way it's done then maybe that's just the
only answer.  We could add some sort of R_RISCV_CALL_SHORT type relocation so
we can emit a correct relocation for relaxed calls without relying on
disassembly hueristics.

We could also just stop relaxing calls under --emit-relocs, then we get a
correct output binary with the long calls.

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

Thanks, Alex just pointed Nelson and I at it as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.