[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200129205330.GK30412@brightrain.aerifal.cx>
Date: Wed, 29 Jan 2020 15:53:30 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Static linking is broken after creation of DT_TEXTREL
segment
On Wed, Jan 29, 2020 at 09:41:46PM +0300, Андрей Аладьев wrote:
> Hello. Please use the following docker image
> "puchuu/test_x86_64-gentoo-linux-musl". I will write here complete steps so
> everyone can reproduce this issue.
>
> docker run -it puchuu/test_x86_64-gentoo-linux-musl bash
> env-update && source /etc/profile
> echo "dev-libs/gmp static-libs" > /etc/portage/package.use/gmp
> MAKEOPTS='-j16' emerge -v dev-libs/gmp
> cd /tmp && wget "
> https://raw.githubusercontent.com/andrew-aladev/lzws/master/cmake/checks/GMP/main.c
> "
>
> gcc main.c -static -lgmp -o main && ./main
> We can see that "-static -lgmp" works perfect.
>
> gcc main.c /usr/lib/libgmp.a -o main && ./main
> /usr/lib/gcc/x86_64-gentoo-linux-musl/9.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld:
> /usr/lib/libgmp.a(bdiv_q_1.o): warning: relocation against
> `__gmp_binvert_limb_table' in read-only section `.text'
> /usr/lib/gcc/x86_64-gentoo-linux-musl/9.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld:
> warning: creating a DT_TEXTREL in object
> Segmentation fault (core dumped)
> We can see that direct usage of "/usr/lib/libgmp.a" provided DT_TEXTREL
> segment.
>
> MAKEOPTS='-j16' emerge -v gdb dev-vcs/git
> CFLAGS='-O0 -g -ggdb -ggdb3' CXXFLAGS='-O0 -g -ggdb -ggdb3'
> FEATURES='nostrip' MAKEOPTS='-j16' emerge -v musl gmp
> git clone git://git.musl-libc.org/musl --depth=1 --single-branch -b
> "v1.1.24"
> gcc -O0 -g -ggdb -ggdb3 main.c /usr/lib/libgmp.a -o main && gdb -ex=run -d
> musl ./main
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fe2f8c4f231 in do_relocs (dso=0x7fe2f8c8eb40 <app>,
> rel=0x55af0a0cd568, rel_size=456, stride=3) at ldso/dynlink.c:423
> 423 *reloc_addr = (size_t)base + addend;
> (gdb) where
> #0 0x00007fe2f8c4f231 in do_relocs (dso=0x7fe2f8c8eb40 <app>,
> rel=0x55af0a0cd568, rel_size=456, stride=3) at ldso/dynlink.c:423
> #1 0x00007fe2f8c51e60 in reloc_all (p=0x7fe2f8c8eb40 <app>) at
> ldso/dynlink.c:1328
> #2 0x00007fe2f8c53a03 in __dls3 (sp=0x7ffc82457260) at ldso/dynlink.c:1906
> #3 0x00007fe2f8c52de6 in __dls2b (sp=0x7ffc82457260) at ldso/dynlink.c:1672
> #4 0x00007fe2f8c52d4e in __dls2 (base=0x7fe2f8bba000
> "\177ELF\002\001\001", sp=0x7ffc82457260) at ldso/dynlink.c:1650
> #5 0x00007fe2f8c4e5a0 in _dlstart_c (sp=0x7ffc82457260,
> dynv=0x7fe2f8c8be20) at ldso/dlstart.c:147
> #6 0x00007fe2f8c4e246 in _dlstart () from /lib/ld-musl-x86_64.so.1
> #7 0x0000000000000001 in ?? ()
> #8 0x00007ffc82458635 in ?? ()
> #9 0x0000000000000000 in ?? ()
>
> (gdb) info locals
> base = 0x561041462000 "\177ELF\002\001\001"
> syms = 0x5610414622c8
> strings = 0x561041462478 ""
> sym = 0x0
> name = 0x5610414624f8 "free"
> ctx = 0x7f9eea640b40 <app>
> type = 8
> sym_index = 0
> def = {sym = 0x0, dso = 0x7f9eea640b40 <app>}
> reloc_addr = 0x56104147cf79 <__gmpn_bdiv_q_1+25>
> sym_val = 0
> tls_val = 0
> addend = 131264
> skip_relative = 0
> reuse_addends = 0
> save_slot = 0
>
> (gdb) p laddr(dso, rel[0])
> $27 = (void *) 0x56104147cf79 <__gmpn_bdiv_q_1+25>
>
> (gdb) p dso->loadmap
> $28 = (struct fdpic_loadmap *) 0x0
>
> (gdb) p (dso->base + rel[0])
> $29 = (unsigned char *) 0x56104147cf79 <__gmpn_bdiv_q_1+25> "\300"
>
> We can see that "laddr" provided pointer to "dso->base + rel[0]", than
> switch tried to override it's value and segfault appeared. Pointer is
> wrong, most likely readonly.
>
> You can replace "gcc" with "clang" and everything will be the same. Updated
> binutils to most recent version 2.33.1 and rebuilt toolchain - nothing
> changed. Pointer is still invalid and SEGV_ACCERR appears.
>
> So I think that bug is inside musl itself. Glibc container is the same
> situation works fine. I see no way to create a workaround for this issue.
musl only has limited support for TEXTRELs as a legacy feature, and
only on some archs. It does not support them in PIE executables or
other "new settings".
I think what you're hitting is a somewhat-known issue in libgmp where
it uses PIC-incompatible code for the .a library but not for the .so.
There is no good reason for it to do this; the PIC-compatible code is
just as efficient and should always be used.
I'm not sure if there's a published patch for this issue. One solution
is using --disable-asm or whatever the option is called to turn off
the PIC-incompatible asm. But if you want the performance it would be
preferable to fix it in some other way.
An easy workaround if you don't need PIE is just linking with -no-pie.
Rich
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.
