[llvm-bugs] [Bug 46632] New: Allow relocation sections to appear before their target sections
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Jul 8 03:38:35 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=46632
Bug ID: 46632
Summary: Allow relocation sections to appear before their
target sections
Product: lld
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: ELF
Assignee: unassignedbugs at nondot.org
Reporter: jh7370.2008 at my.bristol.ac.uk
CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com
I'm doing some prototyping work involving splitting up sections in an object
into smaller parts. To go with the split up sections, I split up the relocation
sections too accordingly. Thus in a simplified output, a section might
previously have been:
.foo:
.quad sym1 # reloc 1 in .rela.foo
.quad sym2 # reloc 2 in .rela.foo
Which might get split up into:
.foo[0]:
.quad sym1 # reloc 1 in .rela.foo[0]
.foo[1]:
.quad sym2 # reloc 1 in .rela.foo[1]
As part of this prototype, I've been patching the section header table in
place, by reusing the first section header for the first split section, and
appending new ones to the end, so it might go from:
.foo
.rela.foo
.symtab
to:
.foo[0]
.rela.foo[0]
.symtab
.foo[1]
.rela.foo[1]
So far, this all works fine. However, I've run into a situation where the first
split part does not have corresponding relocations. This means the original
relocation section header slot now contains the relocations for the appended
section header later. For example, the output might look a bit like:
.foo[0]:
.quad 0x1234
.foo[1]:
.quad sym # reloc in .rela.foo[1]
shdr table:
.foo[0]
.rela.foo[1]
.symtab
.foo[1]
Note that this means the relocation section has a sh_info greater than its own
index, unlike typical relocation sections which appear after their target
section. LLD refuses to allow this situation:
C:\llvm\build\Debug\bin\ld.lld .\foo.o -o test.elf
ld.lld: error: .\fooo: unsupported relocation reference
This error appears to be because the association is calculated as soon as the
relocation section is initialised, but if the associated section hasn't been
initialised itself (and it won't have been because sections are initialised in
order), it fails.
As far as I can see, there is nothing in ELF gABI land preventing relocation
sections appearing before their corresponding targets. Whilst obviously this
doesn't happen in normal usage (since it's not what assemblers typically do),
not allowing it makes it harder to write custom tools to do things like I'm
doing.
I don't think a fix would be too complex - it would simply require allowing
sections to be initialised out-of-order as soon as required, and then skipping
them if they've already been initialised once the in-order process reaches
them.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200708/296bb9fa/attachment.html>
More information about the llvm-bugs
mailing list