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

[H. Peter Anvin]

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

They are useful if a postprocessor needs them.