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

[H. Peter Anvin]

On 2025-10-28 09:16, Jan Beulich wrote:
>>
>> I mean a postprocessor lining with using --keep-relocs (sp?, not in front of a computer.)
> 
> I see. In that case the symbols need retaining anyway, as without them the
> relocations can't be expressed. If such an image was to actually be relocated,
> the dynamic loader would then of course also need to know how to deal with
> these STT_RELC / STT_SRELC symbols.
> 

Yes, if the ELF image is used as the loader format, it would indeed.  In the
Z80 or x86-16 cases the built-time postprocessor would have to deal with them
or throw an error for the case when the actual load format would not be able
to express the resulting relocations.

For example, the MS-DOS MZ/EXE format can only express relocations that of the
form addend + (global_base >> 4), which is safe in this case because
global_base is guaranteed to be a multiple of 16.  If the resulting expression
cannot be coerced into this format, then the postprocessor has to throw an error.

For the Z80 case, different operating systems have vastly different
requirements when it comes to relocations, if they support them at all (e.g.
CP/M doesn't support relocation at all.)  If relocation is necessary for an
application but the operating system doesn't natively support them then the
application itself has to carry code to do the relocation fixups. Some
toolchains use some kind of fixed relocations which range in complexity
anywhere from simple 16-bit relocations only to far more complex, but some
toolchains generate ad hoc code on the fly, which at least in theory could
support arbitrarily complex expressions.

	-hpa