[PATCH] D22961: [ELF] - Linkerscript: restrict moving location counter backwards.

George Rimar via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 10 03:10:48 PDT 2016


>>

>>Looks like we should do something for them, but can you describe what we should do? I can't find a simple rule to describe the behavior of GNU linkers.
>
>Description looks to be simple:
>
>"The linker uses a simple heuristic to do this. It attempts to place orphan sections after non-orphan sections of the same attribute, such as code vs data, loadable vs >non-loadable, etc. If there is not enough room to do this then it places at the end of the file."
>(https://sourceware.org/binutils/docs/ld/Orphan-Sections.html?)
>
>George.

And behavior of ld and gold differers here. ld seems makes simple thing: it just tries to place orphan sections after sections of the same attribute and does not watch if there is room or not:

.global _start
_start:
  nop

.section .foo1, "a"
foo1:
 .long 1

.section .foo2, "a"
foo2:
 .long 1

.section .foo3, "a"
foo3:
 .long 1

.section .bar1, "aw"
bar1:
 .long 1


SECTIONS {
. = 0x1000;
.foo1 : { *(.foo1) }
.foo2 : { *(.foo2) }
. = 0x1009;
.bar1 : { *(.bar1) }
}

++ ld start.o -script linker.script -o out
ld: section .foo3 loaded at [0000000000001009,000000000000100c] overlaps section .bar1 loaded at [0000000000001009,000000000000100c]

gold does not show any errors, but its output seems to be broken for my eye:
 [ 1] .foo1             PROGBITS         0000000000001000  00001000
       0000000000000004  0000000000000000   A       0     0     1
  [ 2] .foo2             PROGBITS         0000000000001004  00001004
       0000000000000004  0000000000000000   A       0     0     1
  [ 3] .text             PROGBITS         000000000000100c  0000100c
       0000000000000001  0000000000000000  AX       0     0     4
  [ 4] .foo3             PROGBITS         000000000000100d  0000100d
       0000000000000004  0000000000000000   A       0     0     1
  [ 5] .bar1             PROGBITS         0000000000001030  00001030
       0000000000000004  0000000000000000  WA       0     0     1

Making some room helps ld to work:
SECTIONS {
. = 0x1000;
.foo1 : { *(.foo1) }
.foo2 : { *(.foo2) }
. = 0x1100;
.bar1 : { *(.bar1) }
}

ld output:
  [ 1] .text             PROGBITS         0000000000001000  00001000
       0000000000000001  0000000000000000  AX       0     0     4
  [ 2] .foo1             PROGBITS         0000000000001001  00001001
       0000000000000004  0000000000000000   A       0     0     1
  [ 3] .foo2             PROGBITS         0000000000001005  00001005
       0000000000000004  0000000000000000   A       0     0     1
  [ 4] .foo3             PROGBITS         0000000000001009  00001009
       0000000000000004  0000000000000000   A       0     0     1
  [ 5] .bar1             PROGBITS         0000000000001100  00001100
       0000000000000004  0000000000000000  WA       0     0     1

So I would start with ld behavior. If I am not missing something ld way would be
easy to implement and that should keep code simple at the same way.
I`ll try to prepare a patch.

George.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160810/ee7c9a24/attachment.html>


More information about the llvm-commits mailing list