* Segmentation fault in static binaries built with recent binutils
@ 2018-07-18 16:39 Reiner Herrmann
2018-07-18 17:37 ` Rich Felker
2018-07-18 18:14 ` Reiner Herrmann
0 siblings, 2 replies; 11+ messages in thread
From: Reiner Herrmann @ 2018-07-18 16:39 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Hi,
Debian recently updated binutils from 2.30 to 2.31.
When compiling simple static binaries with musl (1.19 and git)
they segfault on startup (dynamic linking still works fine).
With the previous binutils version it is running successfully.
$ cat test.c
int main() { return 0; }
$ musl-gcc -ggdb3 -O0 -static test.c
$ gdb ./a.out
GNU gdb (Debian 8.1-3) 8.1
[...]
Reading symbols from ./a.out...done.
(gdb) run
Starting program: /tmp/test/a.out
Program received signal SIGSEGV, Segmentation fault.
0x000000000040159d in static_init_tls ()
(gdb) bt
#0 0x000000000040159d in static_init_tls ()
#1 0x0000000000000000 in ?? ()
See also: https://ci.debian.net/packages/m/musl/unstable/amd64/
Is this a bug in musl or should I report it to binutils?
Kind regards,
Reiner
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 16:39 Segmentation fault in static binaries built with recent binutils Reiner Herrmann
@ 2018-07-18 17:37 ` Rich Felker
2018-07-18 18:14 ` Reiner Herrmann
1 sibling, 0 replies; 11+ messages in thread
From: Rich Felker @ 2018-07-18 17:37 UTC (permalink / raw)
To: musl
On Wed, Jul 18, 2018 at 06:39:40PM +0200, Reiner Herrmann wrote:
> Hi,
>
> Debian recently updated binutils from 2.30 to 2.31.
> When compiling simple static binaries with musl (1.19 and git)
> they segfault on startup (dynamic linking still works fine).
> With the previous binutils version it is running successfully.
>
> $ cat test.c
> int main() { return 0; }
> $ musl-gcc -ggdb3 -O0 -static test.c
> $ gdb ./a.out
> GNU gdb (Debian 8.1-3) 8.1
> [...]
> Reading symbols from ./a.out...done.
> (gdb) run
> Starting program: /tmp/test/a.out
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000040159d in static_init_tls ()
> (gdb) bt
> #0 0x000000000040159d in static_init_tls ()
> #1 0x0000000000000000 in ?? ()
>
> See also: https://ci.debian.net/packages/m/musl/unstable/amd64/
>
> Is this a bug in musl or should I report it to binutils?
Can you attach a readelf -a of the binary that's crashing?
Rich
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 16:39 Segmentation fault in static binaries built with recent binutils Reiner Herrmann
2018-07-18 17:37 ` Rich Felker
@ 2018-07-18 18:14 ` Reiner Herrmann
2018-07-18 19:00 ` Szabolcs Nagy
1 sibling, 1 reply; 11+ messages in thread
From: Reiner Herrmann @ 2018-07-18 18:14 UTC (permalink / raw)
To: musl
[-- Attachment #1.1: Type: text/plain, Size: 86 bytes --]
> Can you attach a readelf -a of the binary that's crashing?
The output is attached.
[-- Attachment #1.2: readelf.txt --]
[-- Type: text/plain, Size: 11902 bytes --]
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x40102d
Start of program headers: 64 (bytes into file)
Start of section headers: 28880 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 23
Section header string table index: 22
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .init PROGBITS 0000000000401000 00001000
0000000000000003 0000000000000000 AX 0 0 1
[ 2] .text PROGBITS 0000000000401010 00001010
0000000000000719 0000000000000000 AX 0 0 16
[ 3] .fini PROGBITS 0000000000401729 00001729
0000000000000003 0000000000000000 AX 0 0 1
[ 4] .rodata PROGBITS 0000000000402000 00002000
000000000000000a 0000000000000001 AMS 0 0 1
[ 5] .eh_frame PROGBITS 0000000000402010 00002010
000000000000003c 0000000000000000 A 0 0 8
[ 6] .init_array INIT_ARRAY 0000000000403ff0 00002ff0
0000000000000008 0000000000000008 WA 0 0 8
[ 7] .fini_array FINI_ARRAY 0000000000403ff8 00002ff8
0000000000000008 0000000000000008 WA 0 0 8
[ 8] .data PROGBITS 0000000000404000 00003000
0000000000000008 0000000000000000 WA 0 0 8
[ 9] .bss NOBITS 0000000000404020 00003008
0000000000000278 0000000000000000 WA 0 0 32
[10] .comment PROGBITS 0000000000000000 00003008
000000000000001d 0000000000000001 MS 0 0 1
[11] .debug_aranges PROGBITS 0000000000000000 00003030
00000000000000e0 0000000000000000 0 0 16
[12] .debug_info PROGBITS 0000000000000000 00003110
0000000000000159 0000000000000000 0 0 1
[13] .debug_abbrev PROGBITS 0000000000000000 00003269
00000000000000f1 0000000000000000 0 0 1
[14] .debug_line PROGBITS 0000000000000000 0000335a
0000000000000126 0000000000000000 0 0 1
[15] .debug_frame PROGBITS 0000000000000000 00003480
0000000000000038 0000000000000000 0 0 8
[16] .debug_str PROGBITS 0000000000000000 000034b8
000000000000272a 0000000000000001 MS 0 0 1
[17] .debug_loc PROGBITS 0000000000000000 00005be2
00000000000000d6 0000000000000000 0 0 1
[18] .debug_ranges PROGBITS 0000000000000000 00005cc0
00000000000000a0 0000000000000000 0 0 16
[19] .debug_macro PROGBITS 0000000000000000 00005d60
00000000000007fb 0000000000000000 0 0 1
[20] .symtab SYMTAB 0000000000000000 00006560
00000000000007e0 0000000000000018 21 48 8
[21] .strtab STRTAB 0000000000000000 00006d40
00000000000002b2 0000000000000000 0 0 1
[22] .shstrtab STRTAB 0000000000000000 00006ff2
00000000000000de 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
There are no section groups in this file.
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x000000000000072c 0x000000000000072c R E 0x1000
LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000
0x000000000000004c 0x000000000000004c R 0x1000
LOAD 0x0000000000002ff0 0x0000000000403ff0 0x0000000000403ff0
0x0000000000000018 0x00000000000002a8 RW 0x1000
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
GNU_RELRO 0x0000000000002ff0 0x0000000000403ff0 0x0000000000403ff0
0x0000000000000010 0x0000000000000010 R 0x1
Section to Segment mapping:
Segment Sections...
00 .init .text .fini
01 .rodata .eh_frame
02 .init_array .fini_array .data .bss
03
04 .init_array .fini_array
There is no dynamic section in this file.
There are no relocations in this file.
The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.
Symbol table '.symtab' contains 84 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000401000 0 SECTION LOCAL DEFAULT 1
2: 0000000000401010 0 SECTION LOCAL DEFAULT 2
3: 0000000000401729 0 SECTION LOCAL DEFAULT 3
4: 0000000000402000 0 SECTION LOCAL DEFAULT 4
5: 0000000000402010 0 SECTION LOCAL DEFAULT 5
6: 0000000000403ff0 0 SECTION LOCAL DEFAULT 6
7: 0000000000403ff8 0 SECTION LOCAL DEFAULT 7
8: 0000000000404000 0 SECTION LOCAL DEFAULT 8
9: 0000000000404020 0 SECTION LOCAL DEFAULT 9
10: 0000000000000000 0 SECTION LOCAL DEFAULT 10
11: 0000000000000000 0 SECTION LOCAL DEFAULT 11
12: 0000000000000000 0 SECTION LOCAL DEFAULT 12
13: 0000000000000000 0 SECTION LOCAL DEFAULT 13
14: 0000000000000000 0 SECTION LOCAL DEFAULT 14
15: 0000000000000000 0 SECTION LOCAL DEFAULT 15
16: 0000000000000000 0 SECTION LOCAL DEFAULT 16
17: 0000000000000000 0 SECTION LOCAL DEFAULT 17
18: 0000000000000000 0 SECTION LOCAL DEFAULT 18
19: 0000000000000000 0 SECTION LOCAL DEFAULT 19
20: 0000000000000000 0 FILE LOCAL DEFAULT ABS exit.lo
21: 0000000000401410 2 FUNC LOCAL DEFAULT 2 dummy
22: 0000000000401420 58 FUNC LOCAL DEFAULT 2 libc_exit_fini
23: 0000000000000000 0 FILE LOCAL DEFAULT ABS crt1.c
24: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
25: 0000000000401080 0 FUNC LOCAL DEFAULT 2 deregister_tm_clones
26: 00000000004010b0 0 FUNC LOCAL DEFAULT 2 register_tm_clones
27: 00000000004010f0 0 FUNC LOCAL DEFAULT 2 __do_global_dtors_aux
28: 0000000000404020 1 OBJECT LOCAL DEFAULT 9 completed.7090
29: 0000000000403ff8 0 OBJECT LOCAL DEFAULT 7 __do_global_dtors_aux_fin
30: 0000000000401120 0 FUNC LOCAL DEFAULT 2 frame_dummy
31: 0000000000403ff0 0 OBJECT LOCAL DEFAULT 6 __frame_dummy_init_array_
32: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c
33: 0000000000000000 0 FILE LOCAL DEFAULT ABS __libc_start_main.lo
34: 0000000000401140 2 FUNC LOCAL DEFAULT 2 dummy
35: 0000000000401150 2 FUNC LOCAL DEFAULT 2 dummy1
36: 0000000000401390 50 FUNC LOCAL DEFAULT 2 libc_start_init
37: 0000000000000000 0 FILE LOCAL DEFAULT ABS __init_tls.lo
38: 0000000000401550 378 FUNC LOCAL DEFAULT 2 static_init_tls
39: 0000000000404040 48 OBJECT LOCAL DEFAULT 9 main_tls
40: 0000000000404080 376 OBJECT LOCAL DEFAULT 9 builtin_tls
41: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
42: 0000000000402048 0 OBJECT LOCAL DEFAULT 5 __FRAME_END__
43: 0000000000000000 0 FILE LOCAL DEFAULT ABS
44: 0000000000404000 0 NOTYPE LOCAL DEFAULT 7 __fini_array_end
45: 0000000000403ff8 0 NOTYPE LOCAL DEFAULT 7 __fini_array_start
46: 0000000000403ff8 0 NOTYPE LOCAL DEFAULT 6 __init_array_end
47: 0000000000403ff0 0 NOTYPE LOCAL DEFAULT 6 __init_array_start
48: 0000000000401160 545 FUNC GLOBAL DEFAULT 2 __init_libc
49: 0000000000404200 8 OBJECT GLOBAL HIDDEN 9 __hwcap
50: 00000000004016e7 0 FUNC GLOBAL DEFAULT 2 memcpy
51: 0000000000404008 0 OBJECT GLOBAL HIDDEN 8 __TMC_END__
52: 0000000000404220 112 OBJECT GLOBAL HIDDEN 9 __libc
53: 0000000000404000 0 OBJECT GLOBAL HIDDEN 8 __dso_handle
54: 0000000000401719 0 FUNC GLOBAL DEFAULT 2 __set_thread_area
55: 00000000004014c0 138 FUNC GLOBAL DEFAULT 2 __copy_tls
56: 0000000000404038 8 OBJECT WEAK DEFAULT 9 _environ
57: 0000000000404038 8 OBJECT GLOBAL DEFAULT 9 __environ
58: 00000000004016d0 23 FUNC GLOBAL DEFAULT 2 _Exit
59: 0000000000401550 378 FUNC WEAK DEFAULT 2 __init_tls
60: 0000000000401000 0 NOTYPE GLOBAL DEFAULT 1 _init
61: 0000000000401410 2 FUNC WEAK DEFAULT 2 __funcs_on_exit
62: 00000000004016e7 0 NOTYPE GLOBAL HIDDEN 2 __memcpy_fwd
63: 0000000000404038 8 OBJECT WEAK DEFAULT 9 environ
64: 0000000000404038 8 OBJECT WEAK DEFAULT 9 ___environ
65: 0000000000404030 8 OBJECT GLOBAL DEFAULT 9 __progname
66: 000000000040102d 0 NOTYPE GLOBAL DEFAULT 2 _start
67: 0000000000401050 40 FUNC GLOBAL DEFAULT 2 _start_c
68: 0000000000404030 8 OBJECT WEAK DEFAULT 9 program_invocation_short_
69: 0000000000401390 50 FUNC WEAK DEFAULT 2 __libc_start_init
70: 0000000000401460 95 FUNC GLOBAL DEFAULT 2 __init_tp
71: 0000000000401150 2 FUNC WEAK DEFAULT 2 __init_ssp
72: 0000000000404008 0 NOTYPE GLOBAL DEFAULT 9 __bss_start
73: 0000000000401127 11 FUNC GLOBAL DEFAULT 2 main
74: 0000000000401410 2 FUNC WEAK DEFAULT 2 __stdio_exit
75: 0000000000401729 0 NOTYPE GLOBAL DEFAULT 3 _fini
76: 0000000000401420 58 FUNC WEAK DEFAULT 2 __libc_exit_fini
77: 0000000000404008 0 NOTYPE GLOBAL DEFAULT 8 _edata
78: 0000000000404298 0 NOTYPE GLOBAL DEFAULT 9 _end
79: 0000000000401010 29 FUNC GLOBAL DEFAULT 2 exit
80: 00000000004013d0 61 FUNC GLOBAL DEFAULT 2 __libc_start_main
81: 0000000000404028 8 OBJECT WEAK DEFAULT 9 program_invocation_name
82: 0000000000404290 8 OBJECT GLOBAL HIDDEN 9 __sysinfo
83: 0000000000404028 8 OBJECT GLOBAL DEFAULT 9 __progname_full
No version information found in this file.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 18:14 ` Reiner Herrmann
@ 2018-07-18 19:00 ` Szabolcs Nagy
2018-07-18 19:38 ` Szabolcs Nagy
0 siblings, 1 reply; 11+ messages in thread
From: Szabolcs Nagy @ 2018-07-18 19:00 UTC (permalink / raw)
To: musl
* Reiner Herrmann <reiner@reiner-h.de> [2018-07-18 20:14:38 +0200]:
> > Can you attach a readelf -a of the binary that's crashing?
>
> The output is attached.
i could reproduce the crash in a debian:unstable docker image
i see incorrect auxv[AT_PHDR] value, not yet sure why.
Program received signal SIGSEGV, Segmentation fault.
static_init_tls (aux=aux@entry=0x7fffffffebc0) at ../src/env/__init_tls.c:88
88 if (phdr->p_type == PT_PHDR)
(gdb) disas
Dump of assembler code for function static_init_tls:
0x0000000000401404 <+0>: sub $0x8,%rsp
0x0000000000401408 <+4>: mov 0x18(%rdi),%r9
0x000000000040140c <+8>: mov 0x28(%rdi),%rsi
0x0000000000401410 <+12>: xor %ecx,%ecx
0x0000000000401412 <+14>: xor %eax,%eax
0x0000000000401414 <+16>: mov %r9,%rdx
0x0000000000401417 <+19>: test %rsi,%rsi
0x000000000040141a <+22>: je 0x401456 <static_init_tls+82>
=> 0x000000000040141c <+24>: mov (%rdx),%r8d
...
(gdb) p/x aux[3]
$4 = 0x400040
(gdb) i proc map
process 13499
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x401000 0x402000 0x1000 0x1000 /musl/build/a.out
0x402000 0x403000 0x1000 0x2000 /musl/build/a.out
0x403000 0x405000 0x2000 0x2000 /musl/build/a.out
0x7ffff7ffa000 0x7ffff7ffd000 0x3000 0x0 [vvar]
0x7ffff7ffd000 0x7ffff7fff000 0x2000 0x0 [vdso]
0x7ffffffde000 0x7ffffffff000 0x21000 0x0 [stack]
(gdb) i reg
rax 0x0 0
rbx 0x0 0
rcx 0x0 0
rdx 0x400040 4194368
rsi 0x5 5
rdi 0x7fffffffebc0 140737488350144
rbp 0x1 0x1
rsp 0x7fffffffeb90 0x7fffffffeb90
r8 0x4015a1 4199841
r9 0x400040 4194368
r10 0x0 0
r11 0x0 0
r12 0x7fffffffed58 140737488350552
r13 0x401127 4198695
r14 0x0 0
r15 0x0 0
rip 0x40141c 0x40141c <static_init_tls+24>
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 19:00 ` Szabolcs Nagy
@ 2018-07-18 19:38 ` Szabolcs Nagy
2018-07-18 20:19 ` Szabolcs Nagy
0 siblings, 1 reply; 11+ messages in thread
From: Szabolcs Nagy @ 2018-07-18 19:38 UTC (permalink / raw)
To: musl
* Szabolcs Nagy <nsz@port70.net> [2018-07-18 21:00:24 +0200]:
> * Reiner Herrmann <reiner@reiner-h.de> [2018-07-18 20:14:38 +0200]:
> > > Can you attach a readelf -a of the binary that's crashing?
> >
> > The output is attached.
>
> i could reproduce the crash in a debian:unstable docker image
>
> i see incorrect auxv[AT_PHDR] value, not yet sure why.
>
>
> Program received signal SIGSEGV, Segmentation fault.
> static_init_tls (aux=aux@entry=0x7fffffffebc0) at ../src/env/__init_tls.c:88
> 88 if (phdr->p_type == PT_PHDR)
> (gdb) disas
> Dump of assembler code for function static_init_tls:
> 0x0000000000401404 <+0>: sub $0x8,%rsp
> 0x0000000000401408 <+4>: mov 0x18(%rdi),%r9
> 0x000000000040140c <+8>: mov 0x28(%rdi),%rsi
> 0x0000000000401410 <+12>: xor %ecx,%ecx
> 0x0000000000401412 <+14>: xor %eax,%eax
> 0x0000000000401414 <+16>: mov %r9,%rdx
> 0x0000000000401417 <+19>: test %rsi,%rsi
> 0x000000000040141a <+22>: je 0x401456 <static_init_tls+82>
> => 0x000000000040141c <+24>: mov (%rdx),%r8d
> ...
> (gdb) p/x aux[3]
> $4 = 0x400040
> (gdb) i proc map
> process 13499
> Mapped address spaces:
>
> Start Addr End Addr Size Offset objfile
> 0x401000 0x402000 0x1000 0x1000 /musl/build/a.out
> 0x402000 0x403000 0x1000 0x2000 /musl/build/a.out
> 0x403000 0x405000 0x2000 0x2000 /musl/build/a.out
> 0x7ffff7ffa000 0x7ffff7ffd000 0x3000 0x0 [vvar]
> 0x7ffff7ffd000 0x7ffff7fff000 0x2000 0x0 [vdso]
> 0x7ffffffde000 0x7ffffffff000 0x21000 0x0 [stack]
seems like another musl-gcc wrapper issue, if i do the linking
manually then i get a working binary, havent yet figured out why
manual linking:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0001ec 0x0001ec R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
NOTE 0x0001c8 0x00000000004001c8 0x00000000004001c8 0x000024 0x000024 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
musl-gcc linking:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 19:38 ` Szabolcs Nagy
@ 2018-07-18 20:19 ` Szabolcs Nagy
2018-07-18 20:24 ` Szabolcs Nagy
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Szabolcs Nagy @ 2018-07-18 20:19 UTC (permalink / raw)
To: musl
* Szabolcs Nagy <nsz@port70.net> [2018-07-18 21:38:34 +0200]:
> seems like another musl-gcc wrapper issue, if i do the linking
> manually then i get a working binary, havent yet figured out why
>
> manual linking:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0001ec 0x0001ec R 0x1000
> LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
> LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
> LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
> NOTE 0x0001c8 0x00000000004001c8 0x00000000004001c8 0x000024 0x000024 R 0x4
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
> GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
>
> musl-gcc linking:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
> LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
> LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
> GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
> GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
the difference between the two cases was --build-id
--build-id=sha1 works, --build-id=none segfaults
i assume the note section with the build id happens
to force ld to keep the initial load segment, but
that should be there without any note section, so
it's likely a binutils bug (i see it on 2.30 and
master branch too)
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 20:19 ` Szabolcs Nagy
@ 2018-07-18 20:24 ` Szabolcs Nagy
2018-07-18 20:50 ` Rich Felker
2018-07-18 20:53 ` Reiner Herrmann
2 siblings, 0 replies; 11+ messages in thread
From: Szabolcs Nagy @ 2018-07-18 20:24 UTC (permalink / raw)
To: musl
* Szabolcs Nagy <nsz@port70.net> [2018-07-18 22:19:28 +0200]:
> the difference between the two cases was --build-id
>
> --build-id=sha1 works, --build-id=none segfaults
>
as a work around you can add build-id to the musl-gcc.specs
diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh
index 294e24f7..9b4aa761 100644
--- a/tools/musl-gcc.specs.sh
+++ b/tools/musl-gcc.specs.sh
@@ -23,7 +23,7 @@ libgcc.a%s %:if-exists(libgcc_eh.a%s)
%{shared|pie:crtendS.o%s;:crtend.o%s} $libdir/crtn.o
*link:
--dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}
+--build-id -dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static} %{rdynamic:-export-dynamic}
*esp_link:
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 20:19 ` Szabolcs Nagy
2018-07-18 20:24 ` Szabolcs Nagy
@ 2018-07-18 20:50 ` Rich Felker
2018-07-18 20:53 ` Reiner Herrmann
2 siblings, 0 replies; 11+ messages in thread
From: Rich Felker @ 2018-07-18 20:50 UTC (permalink / raw)
To: musl
On Wed, Jul 18, 2018 at 10:19:28PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2018-07-18 21:38:34 +0200]:
> > seems like another musl-gcc wrapper issue, if i do the linking
> > manually then i get a working binary, havent yet figured out why
> >
> > manual linking:
> >
> > Program Headers:
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0001ec 0x0001ec R 0x1000
> > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
> > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
> > LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
> > NOTE 0x0001c8 0x00000000004001c8 0x00000000004001c8 0x000024 0x000024 R 0x4
> > GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
> > GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
> >
> > musl-gcc linking:
> >
> > Program Headers:
> > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000
> > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000
> > LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000
> > GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
> > GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1
>
> the difference between the two cases was --build-id
>
> --build-id=sha1 works, --build-id=none segfaults
>
> i assume the note section with the build id happens
> to force ld to keep the initial load segment, but
> that should be there without any note section, so
> it's likely a binutils bug (i see it on 2.30 and
> master branch too)
So am I understanding correctly that binutils ld is considering the
program headers section not to be something that has to live in loaded
memory? And it's putting a whole 4k of padding below the first load
segment? These both seem to be significant bugs.
Rich
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 20:19 ` Szabolcs Nagy
2018-07-18 20:24 ` Szabolcs Nagy
2018-07-18 20:50 ` Rich Felker
@ 2018-07-18 20:53 ` Reiner Herrmann
2018-07-18 21:37 ` Szabolcs Nagy
2 siblings, 1 reply; 11+ messages in thread
From: Reiner Herrmann @ 2018-07-18 20:53 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
On Wed, Jul 18, 2018 at 10:19:28PM +0200, Szabolcs Nagy wrote:
> the difference between the two cases was --build-id
>
> --build-id=sha1 works, --build-id=none segfaults
>
> i assume the note section with the build id happens
> to force ld to keep the initial load segment, but
> that should be there without any note section, so
> it's likely a binutils bug (i see it on 2.30 and
> master branch too)
Do you mean you see the bug on 2.30, or the initial load segment?
Because with 2.30 it's working for me (the initial load segment is there).
Thanks for your investigation and the suggested workaround!
Kind regards,
Reiner
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: Segmentation fault in static binaries built with recent binutils
2018-07-18 20:53 ` Reiner Herrmann
@ 2018-07-18 21:37 ` Szabolcs Nagy
2018-07-18 21:49 ` Reiner Herrmann
0 siblings, 1 reply; 11+ messages in thread
From: Szabolcs Nagy @ 2018-07-18 21:37 UTC (permalink / raw)
To: musl
* Reiner Herrmann <reiner@reiner-h.de> [2018-07-18 22:53:20 +0200]:
> On Wed, Jul 18, 2018 at 10:19:28PM +0200, Szabolcs Nagy wrote:
> > the difference between the two cases was --build-id
> >
> > --build-id=sha1 works, --build-id=none segfaults
> >
> > i assume the note section with the build id happens
> > to force ld to keep the initial load segment, but
> > that should be there without any note section, so
> > it's likely a binutils bug (i see it on 2.30 and
> > master branch too)
>
> Do you mean you see the bug on 2.30, or the initial load segment?
> Because with 2.30 it's working for me (the initial load segment is there).
>
> Thanks for your investigation and the suggested workaround!
>
i opened
https://sourceware.org/bugzilla/show_bug.cgi?id=23428
i see the same behaviour on debian sid with
$ ld --version
GNU ld (GNU Binutils for Debian) 2.30.90.20180710
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
i haven't bisected the issue but i suspect both
2.30 and 2.31 branches are affected by some recent
change (but not the initial 2.30 release).
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-07-18 21:49 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-18 16:39 Segmentation fault in static binaries built with recent binutils Reiner Herrmann
2018-07-18 17:37 ` Rich Felker
2018-07-18 18:14 ` Reiner Herrmann
2018-07-18 19:00 ` Szabolcs Nagy
2018-07-18 19:38 ` Szabolcs Nagy
2018-07-18 20:19 ` Szabolcs Nagy
2018-07-18 20:24 ` Szabolcs Nagy
2018-07-18 20:50 ` Rich Felker
2018-07-18 20:53 ` Reiner Herrmann
2018-07-18 21:37 ` Szabolcs Nagy
2018-07-18 21:49 ` Reiner Herrmann
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).