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

[Jan Beulich]

On 27.10.2025 16:12, H. Peter Anvin wrote:
> On October 27, 2025 4:07:39 AM PDT, Jan Beulich <jbeulich@suse.com> wrote:
>> 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.
> 
> I don't define R_RELC at all; it isn't necessary (nor, for that matter, useful). The relocation type is a normal relocation; it *has* to be, because the expression symbol still only provides a value; the relocation type is still needed to indicate *how* to apply the relocation (which bits/bytes to insert the value into.)

Then I must not have found the ld side of the machinery. What I found appears to
require R_RELC together with STT_RELC / STT_SRELC. Care to help me out here?

Jan