From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] About remote debugging and library stripping
Date: Mon, 22 Oct 2012 17:04:46 +0200 [thread overview]
Message-ID: <20121022170446.53af0468@skate> (raw)
In-Reply-To: <20121022144411.GA10398@mail.sceen.net>
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
prev parent reply other threads:[~2012-10-22 15:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 9:18 [Buildroot] About remote debugging and library stripping Richard Braun
2012-10-21 18:27 ` Thomas Petazzoni
2012-10-22 14:44 ` Richard Braun
2012-10-22 15:04 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121022170446.53af0468@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox