[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4426D448C41DED43A39522E6E2C3A13CBC6FA5@QLDC01>
Date: Tue, 21 Jul 2015 04:50:50 +0000
From: Warren Armstrong <WA@...ntessencelabs.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: Segfault in VDSO symbol resolution
Thanks for the answer - I did not see before that there's a 'musl-gcc'. If I use that, then the dynamic
linker is set correctly and the application works as expected.
-----Original Message-----
From: Рысь [mailto:lynx@...server.ru]
Sent: Tuesday, 21 July 2015 2:19 PM
To: musl@...ts.openwall.com
Subject: Re: [musl] Segfault in VDSO symbol resolution
On Tue, 21 Jul 2015 01:23:38 +0000
Warren Armstrong <WA@...ntessencelabs.com> wrote:
> Hi,
>
> I've been trying to compile the latest version of OpenSSL against
> musl. The compilation succeeds after some manual tweaking of config
> files but the test suite fails. I have managed to reproduce the
> failure using a small C program and traced the problem to a segfault
> in __vdsosym, but I've reached the limits of my knowledge and hope
> someone on the list can help me. Details of my setup are below.
>
> Cheers,
> Warren
>
> System:
> uname -a: Linux QLBuild01 3.16.0-qre #5 SMP Wed Jun 17 15:02:01
> AEST 2015 x86_64 x86_64 x86_64 GNU/Linux (Note: This kernel name is
> non-standard but it is a stock 3.16.0 kernel) /etc/issue: Ubuntu
> 14.04.1 LTS gcc version: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
>
> Musl version:
> Git checkout yesterday from:
> git remote show origin
> * remote origin
> Fetch URL: git://git.musl-libc.org/musl
> Push URL: git://git.musl-libc.org/musl
> HEAD branch: master
> Remote branches:
> master tracked
> rs-1.0 tracked
> Local branch configured for 'git pull':
> master merges with remote master
> Local ref configured for 'git push':
> master pushes to master (up to date) Most recent commit:
> 0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0
>
> Musl configuration:
> CFLAGS="-O0" ./configure --prefix=/usr/local/debug-musl
> --enable-debug (The problem first arose with a standard configuration
> specifying only --prefix - I have changed the configuration to make
> GDB useful and the problem persists)
>
> The test program (shell.c):
> #include <time.h>
>
> int main()
> {
> time(NULL);
> return 0;
> }
>
> Test program compilation:
> gcc -nostdlib -L /usr/local/debug-musl/lib/ -isystem
> /usr/local/debug-musl/include/ -o shell shell.c
> /usr/local/debug-musl/lib/crt1.o /usr/local/debug-musl/lib/crti.o -lc
> -lgcc
>
The gcc command line probably misses -Wl,-dynamic-linker -Wl,/path/to/musl.ld.so part
> Dynamic linkage of the test program:
> ldd ./shell
> linux-vdso.so.1 => (0x00007fffc6f3d000)
> libc.so => /usr/local/debug-musl/lib/libc.so
> (0x00007fad75dc2000)
Testing binary with glibc ldd makes no sense,
>
> Gdb output:
> gdb ./shell
> <startup blurb removed>
> Reading symbols from ./shell...done.
> (gdb) run
> Starting program: /home/warmstrong/shell
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7b37726 in __vdsosym (vername=0x7ffff7bd496b "LINUX_2.6",
> name=0x7ffff7bd4956 "__vdso_clock_gettime") at src/internal/vdso.c:45
> 45 for (i=0; libc.auxv[i] != AT_SYSINFO_EHDR; i+=2)
> (gdb) bt #0 0x00007ffff7b37726 in __vdsosym (vername=0x7ffff7bd496b
> "LINUX_2.6", name=0x7ffff7bd4956 "__vdso_clock_gettime") at
> src/internal/vdso.c:45 #1 0x00007ffff7b9ec6e in __clock_gettime
> (clk=0, ts=0x7fffffffe5b0) at src/time/clock_gettime.c:31 #2
> 0x00007ffff7ba081d in time (t=0x0) at src/time/time.c:9 #3
> 0x00000000004003ee in main () (gdb) frame 0 #0 0x00007ffff7b37726 in
> __vdsosym (vername=0x7ffff7bd496b "LINUX_2.6", name=0x7ffff7bd4956
> "__vdso_clock_gettime") at src/internal/vdso.c:45 45 for
> (i=0; libc.auxv[i] != AT_SYSINFO_EHDR; i+=2) (gdb) info locals i = 0
> eh = 0x0 ph = 0x7fffffffe610 dynv = 0x0 base = 1 strings =
> 0x7ffff7de9557 "H\211\305d\213\004%\030"
> syms = 0x7fffffffe5d0
> hashtab = 0x0
> versym = 0x0
> verdef = 0x7fffffffe620
> (gdb) print libc.auxv
> No symbol "libc" in current context.
>
> Readelf output:
> $: readelf -d shell
> Dynamic section at offset 0xed0 contains 14 entries:
> Tag Type Name/Value
> 0x0000000000000001 (NEEDED) Shared library: [libc.so]
> 0x000000000000000c (INIT) 0x4003a0
> 0x000000000000000d (FINI) 0x40041f
> 0x000000006ffffef5 (GNU_HASH) 0x400278
> 0x0000000000000005 (STRTAB) 0x400338
> 0x0000000000000006 (SYMTAB) 0x4002a8
> 0x000000000000000a (STRSZ) 56 (bytes)
> 0x000000000000000b (SYMENT) 24 (bytes)
> 0x0000000000000015 (DEBUG) 0x0
> 0x0000000000000003 (PLTGOT) 0x601000
> 0x0000000000000002 (PLTRELSZ) 48 (bytes)
> 0x0000000000000014 (PLTREL) RELA
> 0x0000000000000017 (JMPREL) 0x400370
> 0x0000000000000000 (NULL) 0x0
>
> $ readelf -l shell
>
> Elf file type is EXEC (Executable file) Entry point 0x4003f5 There are
> 9 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> PHDR 0x0000000000000040 0x0000000000400040
> 0x0000000000400040 0x00000000000001f8 0x00000000000001f8 R E 8
> INTERP 0x0000000000000238 0x0000000000400238
> 0x0000000000400238 0x000000000000001c 0x000000000000001c R 1
> [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
If your system is glibc based then why your produced binary calls glibc dynamic linker? It should call musl one (symlink to libc.so).
> LOAD 0x0000000000000000 0x0000000000400000
> 0x0000000000400000 0x00000000000004a0 0x00000000000004a0 R E
> 200000 LOAD 0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000158 0x0000000000000158 RW
> 200000 DYNAMIC 0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000130 0x0000000000000130 RW 8
> NOTE 0x0000000000000254 0x0000000000400254
> 0x0000000000400254 0x0000000000000024 0x0000000000000024 R 4
> GNU_EH_FRAME 0x0000000000000420 0x0000000000400420
> 0x0000000000400420 0x000000000000001c 0x000000000000001c R 4
> GNU_STACK 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10
> GNU_RELRO 0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000130 0x0000000000000130 R 1
>
> Section to Segment mapping:
> Segment Sections...
> 00
> 01 .interp
> 02 .interp .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.plt .init .plt .text .fini .eh_frame_hdr .eh_frame
> 03 .dynamic .got.plt
> 04 .dynamic
> 05 .note.gnu.build-id
> 06 .eh_frame_hdr
> 07
> 08 .dynamic
>
> $ readelf --dyn-syms shell
>
> Symbol table '.dynsym' contains 6 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND time
> 2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
> __libc_start_main 3: 0000000000601028 0 NOTYPE GLOBAL DEFAULT
> 14 _edata 4: 0000000000601028 0 NOTYPE GLOBAL DEFAULT 14 _end
> 5: 0000000000601028 0 NOTYPE GLOBAL DEFAULT 14 __bss_start
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
