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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.