Re: Adding custom sections to default linker script

[Jonas Maebe <jonas dot maebe at elis dot ugent dot be>]

On 04/09/15 14:25, Erik Christiansen wrote:
> Have you tried using the -e commandline option for that override?

Excellent, that solved my final problem!

Except: everything now works fine (on Linux/x86-64) with "GNU ld version
2.20.51.0.2-5.43.el6 20100205", but crashes and burns with "GNU ld (GNU
Binutils for Ubuntu) 2.24" :/

The linker script fragment I add is:

***
SECTIONS
{
  .fpcdata           :
  {
    KEEP (*(.fpc .fpc.n_version .fpc.n_links))
  }
  .threadvar _edata : { *(.threadvar .threadvar.* .gnu.linkonce.tv.*) }
}
INSERT AFTER .data;
***

I can't use ".data" instead of ".fpcdata", because that conflicts with
the ".data" specification in the default linker script.

With the working configuration, I get (readelf -aW extract):

***
  [Nr] Name              Type            Address          Off    Size
ES Flg Lk Inf Al
...
  [17] .got.plt          PROGBITS        00000000007765d8 1765d8 000050
08  WA  0   0  8
  [18] .data             PROGBITS        0000000000776630 176630 037dd0
00  WA  0   0 16
  [19] .fpcdata          PROGBITS        00000000007ae400 1ae400 000030
00  WA  0   0  8
  [20] .bss              NOBITS          0000000000800000 1ae430 0042b8
00  WA  0   0 16
...

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz
 MemSiz   Flg Align
  PHDR           0x000040 0x0000000000400040 0x0000000000400040 0x000188
0x000188 R E 0x8
  INTERP         0x0001c8 0x00000000004001c8 0x00000000004001c8 0x00001c
0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x1748b0
0x1748b0 R E 0x200000
  LOAD           0x175000 0x0000000000775000 0x0000000000775000 0x039430
0x08f2b8 RW  0x200000
  DYNAMIC        0x175000 0x0000000000775000 0x0000000000775000 0x0001b0
0x0001b0 RW  0x8
  NOTE           0x0001e4 0x00000000004001e4 0x00000000004001e4 0x000020
0x000020 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW  0x8
***

With the non-working one:

***
  [Nr] Name              Type            Address          Off    Size
ES Flg Lk Inf Al
...
  [21] .got.plt          PROGBITS        0000000000767258 167258 000058
08  WA  0   0  8
  [22] .data             PROGBITS        00000000007672b0 1672b0 037de0
00  WA  0   0 16
  [23] .fpcdata          PROGBITS        000000000079f090 19f090 000030
00  WA  0   0  8
  [24] .bss              NOBITS          000000000079f090 39f090 0042c8
00  WA  0   0 16
...

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz
 MemSiz   Flg Align
  PHDR           0x000040 0x0000000000400040 0x0000000000400040 0x0001c0
0x0001c0 R E 0x8
  INTERP         0x000200 0x0000000000400200 0x0000000000400200 0x00001c
0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x167044
0x167044 R E 0x200000
  LOAD           0x167048 0x0000000000767048 0x0000000000767048 0x038078
0x038078 RW  0x200000
  LOAD           0x39f090 0x000000000079f090 0x000000000079f090 0x000000
0x0042c8 RW  0x200000
  DYNAMIC        0x167060 0x0000000000767060 0x0000000000767060 0x0001f0
0x0001f0 RW  0x8
  NOTE           0x00021c 0x000000000040021c 0x000000000040021c 0x000020
0x000020 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000
0x000000 RW  0x10
***

The second binary crashes on startup. If I execute it explicitly via
/lib64/ld-linux-x86-64.so.2 and examine the core dump, I see:

***
Core was generated by `/lib64/ld-linux-x86-64.so.2 ./fpmake'.
Program terminated with signal SIGBUS, Bus error.
#0  memset () at ../sysdeps/x86_64/rtld-memset.S:33
33	../sysdeps/x86_64/rtld-memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../sysdeps/x86_64/rtld-memset.S:33
#1  0x00007f7912a28bf9 in _dl_map_object_from_fd
(name=name@entry=0x7fff02f13d6e "./fpmake", fd=<optimized out>,
fbp=fbp@entry=0x7fff02f11738, realname=<optimized out>,
loader=loader@entry=0x0, l_type=l_type@entry=1, mode=mode@entry=536870912,
    stack_endp=stack_endp@entry=0x7fff02f11730, nsid=nsid@entry=0) at
dl-load.c:1393
#2  0x00007f7912a2ae00 in _dl_map_object (loader=loader@entry=0x0,
name=0x7fff02f13d6e "./fpmake", type=type@entry=1,
trace_mode=trace_mode@entry=0, mode=mode@entry=536870912,
nsid=nsid@entry=0) at dl-load.c:2605
#3  0x00007f7912a26823 in dl_main (phdr=phdr@entry=0x7f7912a22040,
phnum=phnum@entry=7, user_entry=user_entry@entry=0x7fff02f11be8,
auxv=0x7fff02f11db0) at rtld.c:1079
#4  0x00007f7912a39565 in _dl_sysdep_start
(start_argptr=start_argptr@entry=0x7fff02f11cd0,
dl_main=dl_main@entry=0x7f7912a23910 <dl_main>) at ../elf/dl-sysdep.c:249
#5  0x00007f7912a26cf8 in _dl_start_final (arg=0x7fff02f11cd0) at rtld.c:332
#6  _dl_start (arg=0x7fff02f11cd0) at rtld.c:558
#7  0x00007f7912a232d8 in _start ()
(gdb) x/10i $pc
=> 0x7f7912a3c9ba <memset+10>:	rep stos %al,%es:(%rdi)
   0x7f7912a3c9bc <memset+12>:	mov    %rdx,%rax
   0x7f7912a3c9bf <memset+15>:	retq
   0x7f7912a3c9c0 <mempcpy>:	cmp    $0x20,%rdx
   0x7f7912a3c9c4 <mempcpy+4>:	jae    0x7f7912a3ca40 <mempcpy+128>
   0x7f7912a3c9c6 <mempcpy+6>:	test   $0x1,%dl
   0x7f7912a3c9c9 <mempcpy+9>:	je     0x7f7912a3c9d6 <mempcpy+22>
   0x7f7912a3c9cb <mempcpy+11>:	movzbl (%rsi),%ecx
   0x7f7912a3c9ce <mempcpy+14>:	mov    %cl,(%rdi)
   0x7f7912a3c9d0 <mempcpy+16>:	inc    %rsi
(gdb) p/x $rdi
$1 = 0x79f0a0
***

So
1) in the non-working case, there is a separate LOAD command for the
added .fpcdata section (which in turn results in another LOAD command
for the .bss section that follows it)
2) in the non-working case, the crash happens while the dynamic linker
is zeroing the .bss

I'm not sure why either 1) or 2) (even in combination with 1) happens
though.


Jonas