[PATCH 2/2] z80-elf: support complex relocation symbols

[Jan Beulich]

On 26.10.2025 20:44, H. Peter Anvin wrote:
> On 2025-10-17 05:22, Jan Beulich wrote:
>> On 13.10.2025 22:25, H. Peter Anvin wrote:
>>> Some Z80 code, like the z88dk libc, does rely on being able to do
>>> computation between external symbols.
>>>
>>> Enable complex relocation support (expression symbols) on Z80.
>>>
>>> [ Is there any fundamental reason not to do this globally? ]
>>
>> Both for Z80 and for the more general question: Is the rest of the toolchain
>> capable of dealing with that without any adjustments? Are other tools on the
>> target (non-GNU linkers etc) capable of (correctly) consuming such objects?
>>
>> Furthermore, looking at just symbol_relc_make_sym(), I can't help the
>> impression that the symbol names produced there could conflict with (quoted)
>> ordinary symbols. Such potential conflicts would be a reason to be careful
>> with enabling of this functionality.
>>
>> In any event such enabling would imo not only want but need to come with at
>> least one testcase.
> 
> So can we separate out Z80 -- a niche architecture for which I believe no
> other ELF toolchain exists -- and the general case for a bit?
> 
> OBJ_COMPLEX_RELC is enabled on MEP (Toshiba Media Processor) and has been for
> a long time. Are there no test cases there?

gas/testsuite/gas/mep/complex-relocs.exp; I wasn't able to spot any linker
test.

> I didn't come up with the complex symbol format, but presumably, yes, they
> could be created by hand if desired, although the likelihood of an actual
> conflict seems very remote.

Actually I found that these symbols are marked STT_RELC / STT_SRELC, which
ought to eliminate ambiguity.

Otoh a comment in bfd/elflink.c claims R_RELC to be "a reserved elf-wide
relocation type code", which imo contradicts

  RELOC_NUMBER (R_RELC, 1)

sitting in include/elf/mep.h. (Maybe "code" is meant in a more abstract way,
i.e. referring only to the identifier, not the value it expands to.) Makes
me wonder though how for Z80 you got away without defining R_RELC.

> Note again that if that is a problem, *then it already exists*. The linker
> *already* consumes expression symbols unconditionally on all architectures --
> I have verified this.  The only effect of OBJ_COMPLEX_RELC is whether or not
> gas can generate such symbols.

I can't confirm this; the only caller of bfd_elf_perform_complex_relocation()
that I can find is in bfd/elf32-mep.c.

Jan