Home Original page

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

H. Peter Anvin hpa@zytor.com
Tue Oct 28 15:42:45 GMT 2025 
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?
>
>Jan

I mean a postprocessor lining with using --keep-relocs (sp?, not in front of a computer.)
More information about the Binutils mailing list