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

[Jan Beulich]

On 28.10.2025 16:42, H. Peter Anvin wrote:
> On October 28, 2025 8:36:55 AM PDT, Jan Beulich <jbeulich@suse.com> wrote:
>> 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?
> 
> 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.

Jan