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

[Jan Beulich]

On 19.01.2026 17:27, Nick Clifton wrote:
>>>>> +  /* PR33723 and 33789: Allow fixups that reference symbols in
>>>>> +     mergeable sections to be adjusted.  Disallow all others.  */
>>>>> +  if (fixP->fx_addsy != NULL
>>>>> +      && (S_GET_SEGMENT (fixP->fx_addsy)->flags & SEC_MERGE) != 0)
>>>>> +    return true;
> 
>>>> Is this actually correct for RISC-V, though?  I thought that RISC-V
>>>> relocations can significantly alter section layout, which means that the
>>>> offset from the section start that the assembler sees may not match
>>>> reality after relaxation.
>>>
>>> Yes, in general for sections containing code that is true. But this is
>>> for relocations to sections containing mergable (debug) string
>>> tables.
>>
>> Except that above code has no constraint towards "debug sections only".
>> In fact, text (i.e. executable) sections can in principle also be
>> SHF_MERGE, 
> 
> Well yes, theoretically.  But in practice the code section would have
> to consist of code sequences that were all of exactly the same length.
> So apart from a PLT or jump table, I cannot imagine how this particular
> scenario could come about.

Jump tables and alike as the primary construct, yes. Yet you never know
what clever things people come up with.

>> and I'd be curious how merging and relaxing would work
>> together. (What might save us right now is that iirc sections with
>> relocations aren't merged [yet].)
> 
> Which is fortunate indeed.
> 
> I suppose that I could extend the patch to check that the SEC_STRINGS
> flag is also set (on sections where we allow the fixups to be adjusted).
> Would that be better ?

On one hand it would restrict things further, reducing the risk of doing
something when we shouldn't. Otoh certain things then may again not work
that would without the extra check. Somewhere it was mentioned that the
problem is solely with debug data. Hence I was wondering whether to
check SEC_DEBUGGING instead (if that addresses the original issue, of
course), at least for the time being.

Jan