[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