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

[Jan Beulich]

On 15.01.2026 12:17, Nick Clifton wrote:
>   Attached is a small patch which allows the Risc-V assembler to adjust
>   fixups against symbols in mergeable sections.  Doing this results in
>   relocations against the section's symbol instead of local symbols.
> 
>   In theory this would workaround the problem reported in PR 33723 and
>   PR 33789, although I have not actually checked this.  In addition I do
>   not know if the change would break something important for Risc-V.
>   (Although the change does not introduce any new testsuite failures,
>   but I am testing in a cross-compilation environment so native tests
>   were not run).
> 
>   The patch does also help to reduce the size of the symbol table in
>   object files as some local symbols can now be dropped.

Retaining this many symbols in RISC-V is for relaxation, aiui. Relaxation
is done on code (text) only, isn't it? In particular it isn't done on any
debug info. Hence I'd like to re-propose by SEC_DEBUGGING suggestion,
albeit not even limited to mergeable sections. That would likely reduce
symbol table sizes even further.

bool
riscv_fix_adjustable (fixS * fixP)
{
  /* PR33723 and 33789: Allow fixups that reference symbols in
     debugging sections to be adjusted.  Disallow all others.  */
  if (fixP->fx_addsy != NULL
      && (S_GET_SEGMENT (fixP->fx_addsy)->flags & SEC_DEBUGGING) != 0)
    return true;

  return false;
}

Part of the reason being that I fear there are bigger problems with
labels in mergeable sections. Take this example:

	.section .rodata.1, "aMS", @progbits, 1
As:
	.asciz "a"
Ae:
Bs:
	.asciz "b"
Be:
Cs:
	.asciz "c"
Ce:

As a human you may recognize that the labels are meant as start/end ones.
But how would a machine know that Ae needs to move with the "a" string,
while Bs needs to move with the "b" one? Without making the symbols global,
under certain conditions they can be lost altogether during linking. If
they're not lost, and if they're not in the first object contributing to
the section, they're almost certainly useless in the output binary.

Hence I wonder: Shouldn't we at least warn about the use of labels in
mergeable sections, when their use needs representing in the object (e.g.
by way of a relocation [1])? And shouldn't we hence strive to replace as
many of the uses as possible by section symbols? Afaict that would then
eliminate the need for a RISC-V-specific code change (which may otherwise
be similarly required for at least all other ELF targets presently
defining tc_fix_adjustable() to constant 0 / false).

Jan

[1] Arguably already the entering into a symbol table is a problem, as
the corresponding symbol in the final object's symbol table would then
also likely be wrong.