RFC: Risc-V: Allow assembler to adjust relocs against symbols in mergeable sections

[Michael Matz]

Hello,

On Tue, 20 Jan 2026, Jan Beulich wrote:

> > % readelf -W -r g.o
> > 
> > Relocation section '.rela.text' at offset 0x160 contains 1 entry:
> >     Offset             Info             Type               Symbol's
> > Value  Symbol's Name + Addend
> > 000000000000000a  0000000300000002 R_X86_64_PC32
> > 0000000000000000 .LC0 - 4
> > 
> > Due to linker's merge section optimization, the byte located at an
> > offset of -4 from .LC0 in the final executable may not be the same
> > byte that was at that offset in the original relocatable file.
> 
> But isn't that a bug in the linker then?

Bug is a too strong word.  It's a tough decision to make: Given a 
relocation with value S+A (symbol plus addend) what is the "thing" it 
references?
  (a) the symbol S
  (b) the thing at logical address addressof(S)+A
there are arguments for both interpretations, and with normal cat-content 
semantics of sections there's no distinction that matters.  But with 
merging semantics it matters what the referenced item is.

The difference between the two is how the addend came to be: was it 
somehow related to the thing that's referenced (interpretation b), or is 
it a technicality, like it is for the PC-relative code relocs on x86-64, 
that always include the -4 offset in the addend (interpretation a)?

There is a sub-choice to make in the above: does the choice depend on if 
S is a section symbol vs. a normal symbol?

Merging semantics currently chose interpretation (b) for relocs against 
section syms: the addend is an integral part of the referenced thing.  
That enables it to work on references of the form sectionsymbol+addend.  
It's also the only logical choice when S is a sectionsym.  But it creates 
problems for references where the addend is a technicality, like seen 
here.  Using the other interpretation would make it work here, but not for 
sectionsym+addend anymore.

And no interpretation works when the addend is a result of merging both, 
an item offset and a technicality.  So we should avoid adding addends of 
different provenance together.  In this case we need to avoid converting a 
pc-relative x86-64 code-reloc (which must have a technical addend -4) into 
a section-relative reloc, because that would add an item-related offset 
into the addend, creating confusion between the two interpretations.

There is no problem in such conversion generally if the addend provenance 
remains unchanged during reloc conversion (e.g. for architectures where 
such technical -4 offset would be part of the relocation semantics, not 
part of the explicit addend).

It would have been better if the initial x86-64 psABI would have included 
explicit code relocations that imply the -4 offset instead of noting that 
in the reloc addend, in that case we wouldn't have to worry about any of 
this.  But that boat has sailed a long time ago.


Ciao,
Michael.