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

[H. Peter Anvin]

On October 17, 2025 5:22:16 AM PDT, Jan Beulich <jbeulich@suse.com> 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.
>
>Jan

I have tested it and haven't had any problems with it. Non-GNU linkers might not support it, though, but those projects rely on even more obscure linkers now.

I don't even know how many Z80 ELF toolchains exist at all. Most projects I have chatted with a couple switching to ELF with switching to GNU binutils.

Those symbols are only used if ELF relocations cannot represent the relevant expressions. 

Ok, I lied to some extent: there *is* a problem with them: there isn't a way to either manually or automatically generate an expression relocation that ends up post-link relocatable, without ad hoc postprocessing of the .o files. This, however, is a much smaller problem than not having any way to represent those kinds of expressions at all; nor is it an issue for the projects for which this is an immediate blocker, like z88dk, as their main use of this is to compute products of absolute symbols and differences between two symbols (i.e. the size of a region, without having to add ad hoc code in the linker script, which doesn't work for libraries.)

Another platform which could benefit from this is, perhaps ironically, x86, for real-mode code, where it is relatively common to need to represent symbols as (value-segbase), (segbase >> 4) pairs, with the segbase value being a linktime constant (the VMA of an output section, not *necessarily* the same output section  as where "value" is defined, either. 

If ld enables this for x86 I intend to add support for it in NASM.