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

[Jan Beulich]

On 17.10.2025 20:14, H. Peter Anvin wrote:
> 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.)

Here and elsewhere, because of the potential conflict I'd accept enabling of the
feature for this target (or, as you suggest, all of them) if it required a
command line option or directive to come into play. Then, if people use it, they're
responsible for not producing symbols with names that could cause conflicts.

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

Hmm, this might have been useful back when there were actually 16-bit programs.
With the little use of 16-bit code nowadays, I don't expect it would be overly
useful (but feel free to educate me). Such 16-bit code is commonly embedded in
bigger 32- or 64-bit binaries (boot loaders, kernels etc), and the 16-bit code then
often doesn't live at a linked address which matches its final resting place. IOW
segbase wouldn't be a link-time constant. It may not even be a load-time constant,
as that code (see e.g. Linux'es and Xen's real-mode trampolines) still needs moving
into an available low-memory location, which is runtime determined.

Jan