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

[H. Peter Anvin]

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.
>
>Jan

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.)

   -hpa