[Buildroot] About remote debugging and library stripping

[Buildroot] About remote debugging and library stripping

[Richard Braun]

Hello,

There seems to be some confusion about what has to be done to get remote
debugging actually working with stripped libraries. It seems buildroot
avoids stripping libthread_db entirely, which was introduced by Mike
Frysinger (hello Mike) with c98bc88e3296222a20e59cfb7b9f3ec5aee3be1c.
If you're absolutely certain of this change, then please explain it.
In my experience (and some in-depth search in the sources), libthread_db
and libpthread can both be stripped.

To understand why this is possible, the big picture must get clearer.
First, for those who aren't aware of its existence, libthread_db is part
of the C library. Its purpose is to hide the implementation details of
the threading implementation through a well defined interface that GDB
and gdbserver can use. When gdbserver loads this library, it doesn't
need the debugging or local symbols. The libthread_db library can be
stripped as much as any other library.

This isn't the case for libpthread. As stated in the GDB FAQ [1],
libthread_db actually needs a few local symbols to work with its
libpthread counterpart. The libpthread library should only be stripped
from its debugging symbols (--strip-debug), not its local ones.

To make things even more complicated, gdbserver (and apparently only
gdbserver) has support for Linux threads since before 2008 [2], but
it's limited (you may get weird SIGTRAPs without understanding why).
This is important because currently, libthread_db isn't installed when
using the crosstool-ng backend.

In the hope this will help.

-- 
Richard Braun

[1] http://sourceware.org/gdb/wiki/FAQ
[2] http://sourceware.org/ml/gdb-patches/2007-10/msg00547.html

[Buildroot] About remote debugging and library stripping

[Thomas Petazzoni]

Richard,

Thanks a lot for this status.

On Fri, 19 Oct 2012 11:18:57 +0200, Richard Braun wrote:

> There seems to be some confusion about what has to be done to get
> remote debugging actually working with stripped libraries. It seems
> buildroot avoids stripping libthread_db entirely, which was
> introduced by Mike Frysinger (hello Mike) with
> c98bc88e3296222a20e59cfb7b9f3ec5aee3be1c. If you're absolutely
> certain of this change, then please explain it. In my experience (and
> some in-depth search in the sources), libthread_db and libpthread can
> both be stripped.
> 
> To understand why this is possible, the big picture must get clearer.
> First, for those who aren't aware of its existence, libthread_db is
> part of the C library. Its purpose is to hide the implementation
> details of the threading implementation through a well defined
> interface that GDB and gdbserver can use. When gdbserver loads this
> library, it doesn't need the debugging or local symbols. The
> libthread_db library can be stripped as much as any other library.
> 
> This isn't the case for libpthread. As stated in the GDB FAQ [1],
> libthread_db actually needs a few local symbols to work with its
> libpthread counterpart. The libpthread library should only be stripped
> from its debugging symbols (--strip-debug), not its local ones.
> 
> To make things even more complicated, gdbserver (and apparently only
> gdbserver) has support for Linux threads since before 2008 [2], but
> it's limited (you may get weird SIGTRAPs without understanding why).
> This is important because currently, libthread_db isn't installed when
> using the crosstool-ng backend.

Can you conclude with what you think are the steps needed to get these
things right?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] About remote debugging and library stripping

[Richard Braun]

On Sun, Oct 21, 2012 at 08:27:19PM +0200, Thomas Petazzoni wrote:
> Can you conclude with what you think are the steps needed to get these
> things right?

First, fix the crosstool-ng backend so that libthread_db gets installed.
The minimal Linux support in gdbserver can lead to serious headaches, so
it's really better to have this library present in the rootfs.

An option could be added that would govern the installation of
libthread_db for people who are looking for a truely minimalist rootfs
and don't intend to debug.

Next, strip libpthread using --strip-debug, and *not* --strip-unneeded,
although this is purely to make sure debugging will work, as the
requirement to keep some local symbols also depends on the libc and the
target, and there are sufficiently few such symbols to consider the
overhead completely negligible (although it could also depend on the
aforementioned option).

If noone works on this, I'll submit a patch when I can make some time
for it.

-- 
Richard Braun

[Buildroot] About remote debugging and library stripping

[Thomas Petazzoni]

On Mon, 22 Oct 2012 16:44:11 +0200, Richard Braun wrote:
> On Sun, Oct 21, 2012 at 08:27:19PM +0200, Thomas Petazzoni wrote:
> > Can you conclude with what you think are the steps needed to get these
> > things right?
> 
> First, fix the crosstool-ng backend so that libthread_db gets installed.
> The minimal Linux support in gdbserver can lead to serious headaches, so
> it's really better to have this library present in the rootfs.

Ok.

> An option could be added that would govern the installation of
> libthread_db for people who are looking for a truely minimalist rootfs
> and don't intend to debug.

I am not sure what happens with the Crosstool-NG when one enables
BR2_PACKAGE_GDB_SERVER and/or BR2_PACKAGE_GDB_HOST. But I guess we
should copy libthread_db to the target only if BR2_PACKAGE_GDB_SERVER
is enabled, i.e if gdbserver is actually installed on the target.

*But*, to keep things consistent, we should also do the same with the
external toolchain backend, i.e only install libthread_db if
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY is enabled. At the moment, the
ext-tool.mk is installing libthread_db on the target only if
BR2_PACKAGE_GDB_SERVER is enabled, which is silly because this option
is not visible in the external toolchain backend case (we assume that
both cross-gdb and gdbserver are provided by the external toolchain).

> Next, strip libpthread using --strip-debug, and *not* --strip-unneeded,
> although this is purely to make sure debugging will work, as the
> requirement to keep some local symbols also depends on the libc and the
> target, and there are sufficiently few such symbols to consider the
> overhead completely negligible (although it could also depend on the
> aforementioned option).
> 
> If noone works on this, I'll submit a patch when I can make some time
> for it.

Ok.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com