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

[Jan Beulich]

On 28.10.2025 16:26, H. Peter Anvin wrote:
> On October 28, 2025 2:11:18 AM PDT, Jan Beulich <jbeulich@suse.com> wrote:
>> On 27.10.2025 23:37, H. Peter Anvin wrote:
>>> On 2025-10-26 15:06, Maciej W. Rozycki wrote:
>>>> On Sun, 26 Oct 2025, H. Peter Anvin wrote:
>>>>
>>>>>>  Possibly, though as usually with BFD I suspect there's a catch; also I 
>>>>>> guess a lot of complication in the MIPS backend comes from the use of said 
>>>>>> odd n64 encoding (triple relocs in a single Elf64_Rela entry).
>>>>>
>>>>> I have done it as a prototype, it is trivial, at least for i386. No problems
>>>>> at all.
>>>>>
>>>>> It is literally a matter of moving the zeroing of a variable out of a loop.
>>>>
>>>>  Does it work as expected, i.e. identical output section contents, when 
>>>> you link to a srec output (such as with `ld --oformat=srec ...')?
>>>>
>>>
>>> I just tried it, and it does not; it errors out:
>>>
>>> /opt/z80/bin/z80-none-elf-ld: expreloc.o: in function `_start':
>>> (.text+0x1): undefined reference to
>>> `*:s15:CONSOLE_COLUMNS:+:s12:CONSOLE_ROWS:#ffffffff'
>>> /opt/z80/bin/z80-none-elf-ld: (.text+0x5): undefined reference to
>>> `-:s3:foo:s11:__IY_BASE__'
>>> /opt/z80/bin/z80-none-elf-ld: (.text+0x7): undefined reference to
>>> `+:s5:pizza:*:s15:CONSOLE_COLUMNS:+:s12:CONSOLE_ROWS:#ffffffff'
>>> /opt/z80/bin/z80-none-elf-ld: (.text+0xa): undefined reference to
>>> `+:s5:pizza:s13:CONSOLE_BYTES'
>>> /opt/z80/bin/z80-none-elf-ld: (.text+0x16): undefined reference to
>>> `+:+:s5:pizza:*:#00000002:s15:CONSOLE_COLUMNS:<<:+:s12:CONSOLE_ROWS:#ffffffff:#00000002'
>>>
>>> Linking to ELF and then using objcopy to srec works correctly, even with stock
>>> binutils ld (no modifications whatsoever).
>>>
>>> There are , in fact, no R_RELC anywhere in the object file. The relocations
>>> are all R_Z80_* but of course the type is set to SHT_RELC.
>>>
>>> Relocation section '.rela.text' at offset 0x270 contains 7 entries:
>>>  Offset     Info    Type            Sym.Value  Sym. Name + Addend
>>> 00000001  00000c04 R_Z80_16          00000000   *:s15:CONSOLE_COL[...] + 0
>>> 00000005  00000d02 R_Z80_8_DIS       00000000   -:s3:foo:s11:__IY[...] + 0
>>> 00000007  00000e04 R_Z80_16          00000000   +:s5:pizza:*:s15:[...] + 0
>>> 0000000a  00000f04 R_Z80_16          00000000   +:s5:pizza:s13:CO[...] + 0
>>> 0000000d  00000a04 R_Z80_16          00000000   pizza + 730
>>> 00000010  00000b04 R_Z80_16          00000000   CONSOLE_BYTES + 0
>>> 00000016  00001004 R_Z80_16          00000000   +:+:s5:pizza:*:#0[...] + 0
>>
>> Hmm, same for the MeP testcase. Things appear to be working from STT_RELC /
>> STT_SRELC, as checked for by elf_link_input_bfd(). Which then also explains
>> why things don't work when linking to other than an ELF output. Another
>> example where logic solely depending on input properties is wrongly tied
>> to the output format (just very recently I fixed a similar issue in section
>> merging). Of course the symbol _types_ wouldn't be representable in non-
>> ELF output; perhaps those symbols then may simply need dropping. (I'm not
>> sure they're overly useful in an ELF executable's static symbol table
>> either.)
>>
>> Interestingly in objdump's symbol table output I can't spot any notion of
>> STT_RELC / STT_SRELC (or even STT_TLS) at all, so the connection became
>> apparent to me only when using my own dumping tool.
> 
> They are useful if a postprocessor needs them.

I'm having some trouble there - if the relocations are gone, what would a post-
processor do with (just) the symbols?

Jan