Home Original page

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

H. Peter Anvin hpa@zytor.com
Mon Oct 27 15:30:53 GMT 2025 
On October 27, 2025 8:23:39 AM PDT, Jan Beulich <jbeulich@suse.com> wrote:
>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

I will look at it again hopefully this evening, but I can't promise.
More information about the Binutils mailing list