Re: Static application with --dynamic-list crashes

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 15/03/17 08:08, Alexey Neyman wrote:
> Hi,
> 
> I've noticed a strange behavior and I am not sure if it is a bug, and if it is - whether it is in gcc, binutils
> or glibc.
> 
> The problem I noticed was that in crosstool-ng, when a gdbserver is linked statically, it requests a strange
> path as the dynamic linker (/lib/ld64.so.1). This path is the default in ld when it creates a dynamically
> linked application and there was no --dynamic-linker= option passed in. In this case, the application was
> linked with "-static -Wl,--dynamic-list=some.file". With these options, GCC does not pass --dynamic-linker
> (because -static is in effect) - but ld thinks it links a dynamically linked app because of the --dynamic-list.
> 

oh i thought it only affected gdb, not gdbserver.
if gdbserver is broken with static linking that's
a huge bug.

> So the first question is, does it even make sense to link a binary with these options? I'd say there may be a
> use case - after all, glibc allows dlopen() from a statically linked binary, and all --dynamic-list does is
> exports some symbols from the application if one does dlopen(NULL, ...).
> 
> I also tried to experiment a bit. It turned out that if I create /lib/ld64.so.1 as a symlink to
> ld-linux-x86-64.so.2, it makes GLIBC crash. It also crashes if I pass
> --dynamic-linker=/lib/ld-linux-x86-64.so.2, or if I pass --no-dynamic-linker.
> 
> I then created a small script (attached) that exercised these options on various libcs (by chrooting into an
> environment with GLIBC, uClibc-ng & musl. Here is the summary:
> 
> '-static --Wl,--dynamic-list=foo.list'
> * Resulted in "./foo: No such file or directory" with all three libcs
> 
> '-static --Wl,--dynamic-list=foo.list -Wl,--no-dynamic-linker'
> * GLIBC either crashed or hung; stock 2.25 crashed for x86_64/i686/x32; Ubuntu 16.10 glibc also crashed with
> x86_64/x32 but i686 version instead hung indefinitely
> * uClibc-ng crashed on i686 and did not crash on x86_64, but dlopen(NULL) returned error
> * musl did not crash on either x86_64/i686, but dlopen(NULL) returned error on both
> 
> '-static --Wl,--dynamic-list=foo.list -Wl,--dynamic-linker=LDSO' (where LDSO is the appropriate path for a
> given architecture/libc
> * GLIBC crashed on x86_64/i686/x32, both stock 2.25 and Ubuntu's
> * uClibc-ng and musl did not crash on either x86_64/i686 but again, dlopen(NULL) failed on both.
> 
> Thoughts?

this is a nasty regression in binutils:

https://sourceware.org/ml/binutils/2017-01/msg00431.html

musl has no dlopen support with static linking (yet)
(and it is not trivial to get it to work sensibly,
the glibc approach is mostly broken: requires a glibc
installation of the right version on the target which
defeats the purpose of static linking)

the good news is that none of the dlopened dsos
should matter for gdb (it can work without threaddb
etc) so i think gdb should be fixed to have a
workaround for the binutils bug (but i don't have
an immediate solution).