[Buildroot] [pull request] Pull request for branch for-2011.11/debugging-improvements

[Buildroot] [pull request] Pull request for branch for-2011.11/debugging-improvements

[Thomas Petazzoni]

The following changes since commit e687bb71a028303f326aeebfaf94a3ac1c43b4e4:

  gcc: bump 4.4.x version (2012-03-13 16:27:25 +0100)

are available in the git repository at:
  git://git.free-electrons.com/users/thomas-petazzoni/buildroot.git for-2011.11/debugging-improvements

Thomas Petazzoni (3):
      debug: do not force installation of gdbserver
      debug: provide an option to copy the gdbserver to the target
      config: improve help text and prompt for debugging related options

 Config.in                                |   33 ++++++++++++++++++-----------
 toolchain/gdb/Config.in                  |    8 +++++++
 toolchain/toolchain-external/ext-tool.mk |   14 ++++++++++++
 3 files changed, 42 insertions(+), 13 deletions(-)

Thanks,
-- 
Thomas Petazzoni

[Buildroot] [PATCH 1/3] debug: do not force installation of gdbserver

[Thomas Petazzoni]

The BR2_ENABLE_DEBUG option selects the compilation and installation
of gdbserver on the target. This is a bit restrictive, especially for
external toolchains, which may already contain a gdbserver on the
target.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 Config.in |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/Config.in b/Config.in
index 2002996..e07e52f 100644
--- a/Config.in
+++ b/Config.in
@@ -205,7 +205,6 @@ config BR2_DEPRECATED
 
 config BR2_ENABLE_DEBUG
 	bool "build packages with debugging symbols"
-	select BR2_PACKAGE_GDB_SERVER
 	help
 	  Build packages with debugging symbols
 	  enabled
-- 
1.7.4.1

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Thomas Petazzoni]

When an external toolchain is used, it is very likely that it contains
a pre-built version of a gdbserver that has the same version as the
cross-gdb included in the external toolchain. So, we now provide an
option that allows to copy this pre-built gdbserver to the target.

As the location of the gdbserver in the external toolchain is not
standardized, we only support the CodeSourcery and Crosstool-NG
layouts for the moment. Other locations can be added later.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 toolchain/gdb/Config.in                  |    8 ++++++++
 toolchain/toolchain-external/ext-tool.mk |   14 ++++++++++++++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
index 8501983..980666b 100644
--- a/toolchain/gdb/Config.in
+++ b/toolchain/gdb/Config.in
@@ -14,10 +14,18 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain"
 
 config BR2_PACKAGE_GDB_SERVER
 	bool "Build gdb server for the Target"
+	depends on !BR2_TOOLCHAIN_EXTERNAL
 	help
 	    Build the gdbserver stub to run on the target.
 	    A full gdb is needed to debug the progam.
 
+config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
+	bool "Copy gdb server to the Target"
+	depends on BR2_TOOLCHAIN_EXTERNAL
+	help
+	  Copy the gdbserver provided by the external toolchain to the
+	  target.
+
 config BR2_PACKAGE_GDB_HOST
 	bool "Build gdb for the Host"
 	# cross-gdb is supposed to be part of the external
diff --git a/toolchain/toolchain-external/ext-tool.mk b/toolchain/toolchain-external/ext-tool.mk
index 01ab91f..6e9686c 100644
--- a/toolchain/toolchain-external/ext-tool.mk
+++ b/toolchain/toolchain-external/ext-tool.mk
@@ -371,6 +371,20 @@ $(STAMP_DIR)/ext-toolchain-installed: $(STAMP_DIR)/ext-toolchain-checked
 	if [ -L $${ARCH_SYSROOT_DIR}/lib64 ] ; then \
 		$(call create_lib64_symlinks) ; \
 	fi ; \
+	if test x"$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY)" == x"y"; then \
+		gdbserver_found=0 ; \
+		for d in $${ARCH_SYSROOT_DIR} $${ARCH_SYSROOT_DIR}/../debug-root/ ; do \
+			if test -f $${d}/usr/bin/gdbserver ; then \
+				install -m 0755 -D $${d}/usr/bin/gdbserver $(TARGET_DIR)/usr/bin/gdbserver ; \
+				gdbserver_found=1 ; \
+				break ; \
+			fi ; \
+		done ; \
+		if [ $${gdbserver_found} -eq 0 ] ; then \
+			echo "Could not find gdbserver in external toolchain" ; \
+			exit 1 ; \
+		fi ; \
+	fi ; \
 	touch $@
 
 # Build toolchain wrapper for preprocessor, C and C++ compiler, and setup
-- 
1.7.4.1

[Buildroot] [PATCH 3/3] config: improve help text and prompt for debugging related options

[Thomas Petazzoni]

The help text for the choice of different stripping levels is removed,
since it is not displayed by menuconfig. Instead, only the per-option
help text is visible, so this text is improved.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 Config.in |   32 ++++++++++++++++++++------------
 1 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/Config.in b/Config.in
index e07e52f..2edeae2 100644
--- a/Config.in
+++ b/Config.in
@@ -206,8 +206,12 @@ config BR2_DEPRECATED
 config BR2_ENABLE_DEBUG
 	bool "build packages with debugging symbols"
 	help
-	  Build packages with debugging symbols
-	  enabled
+	  Build packages with debugging symbols enabled. All libraries
+	  and binaries in the 'staging' directory will have debugging
+	  symbols, which allows remote debugging even if libraries and
+	  binaries are stripped on the target. Whether libraries and
+	  binaries are stripped on the target is controlled by the
+	  BR2_STRIP_* options below.
 
 if BR2_ENABLE_DEBUG
 choice
@@ -240,32 +244,36 @@ endchoice
 endif
 
 choice
-	prompt "strip"
+	prompt "strip command for binaries on target"
 	default BR2_STRIP_strip
-	help
-	  Select whether to strip binaries and libraries for the target
-	  or not.
-	  strip   is the normal strip command
-	  sstrip  is a strip that discards more than the normal strip
-	  none    do not strip (only for debugging!)
 
 config BR2_STRIP_strip
 	bool "strip"
 	depends on !BR2_ELF2FLT
 	help
-	  strip   is the normal strip command
+	  Binaries and libraries in the target filesystem will be
+	  stripped using the normal 'strip' command. This allows to
+	  save space, mainly by removing debugging symbols. Debugging
+	  symbols on the target are unneeded on the target when remote
+	  debugging is used.
 
 config BR2_STRIP_sstrip
 	bool "sstrip"
 	select BR2_PACKAGE_SSTRIP_HOST
 	depends on !BR2_ELF2FLT
 	help
-	  sstrip  is a strip that discards more than the normal strip
+	  Binaries and libraries in the target filesystem will be
+	  stripped using the 'sstrip' command, which strips a little
+	  bit more than the traditional 'strip' command. This allows
+	  to save space, mainly by removing debugging
+	  symbols. Debugging symbols on the target are unneeded on the
+	  target when remote debugging is used.
 
 config BR2_STRIP_none
 	bool "none"
 	help
-	  none    do not strip (only for debugging!)
+	  Do not strip binaries and libraries in the target
+	  filesystem.
 endchoice
 
 choice
-- 
1.7.4.1

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> When an external toolchain is used, it is very likely that it contains
 Thomas> a pre-built version of a gdbserver that has the same version as the
 Thomas> cross-gdb included in the external toolchain. So, we now provide an
 Thomas> option that allows to copy this pre-built gdbserver to the target.

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 3/3] config: improve help text and prompt for debugging related options

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> The help text for the choice of different stripping levels is removed,
 Thomas> since it is not displayed by menuconfig. Instead, only the per-option
 Thomas> help text is visible, so this text is improved.

Committed with minor tweaks, thanks:
 
 Thomas>  config BR2_STRIP_strip
 Thomas>  	bool "strip"
 Thomas>  	depends on !BR2_ELF2FLT
 Thomas>  	help
 Thomas> -	  strip   is the normal strip command
 Thomas> +	  Binaries and libraries in the target filesystem will be
 Thomas> +	  stripped using the normal 'strip' command. This allows to
 Thomas> +	  save space, mainly by removing debugging symbols. Debugging
 Thomas> +	  symbols on the target are unneeded on the target when remote
 Thomas> +	  debugging is used.

I don't like the double target and the fact that we don't explain when
you would want debug symbols on the target, so I changed the last
sentence to be:

Debugging symbols on the target are needed for native debugging, but
not when remote debugging is used.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Daniel Nilsson]

On 03/15/2012 11:05 PM, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni<thomas.petazzoni@free-electrons.com>  writes:
>
>   Thomas>  When an external toolchain is used, it is very likely that it contains
>   Thomas>  a pre-built version of a gdbserver that has the same version as the
>   Thomas>  cross-gdb included in the external toolchain. So, we now provide an
>   Thomas>  option that allows to copy this pre-built gdbserver to the target.
>
> Committed, thanks.
>

Hi Thomas,

I have attempted to build a root filesystem for QEMU/x86 based on the current 
version of buildroot in git (0242ae4c6b7d1daf85a5f0c191394b0a15f95c54). The RFS
is built using an external toolchain (Code Sourcery 2011.09). All seems fine 
except that copying the gdbserver to the target fails, this is since the 
toolchain does not keep the gdbserver where the ext-tool.mk expect to find it,
it is present in these two locations:

host/usr/i686-unknown-linux-gnu/sysroot/usr/lib64/bin/gdbserver
host/usr/i686-unknown-linux-gnu/sysroot/usr/lib/bin/gdbserver


The below patch works around this issue in my case, however I'm not so sure this
is a proper "fix" since it will not work when the 64-bit version is requested.
I'm not sure how the framework is setup to determine 32/64bit versions in this case
so I didn't attempt to fix it.

I have attached my config file below for reference, maybe there is a config option I
need to set?

Regards
Daniel Nilsson




 toolchain/toolchain-external/ext-tool.mk |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/toolchain/toolchain-external/ext-tool.mk b/toolchain/toolchain-external/ext-tool.mk
index a45603a..7101e1f 100644
--- a/toolchain/toolchain-external/ext-tool.mk
+++ b/toolchain/toolchain-external/ext-tool.mk
@@ -388,9 +388,9 @@ $(STAMP_DIR)/ext-toolchain-installed: $(STAMP_DIR)/ext-toolchain-checked
        fi ; \
        if test x"$(BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY)" == x"y"; then \
                gdbserver_found=0 ; \
-               for d in $${ARCH_SYSROOT_DIR} $${ARCH_SYSROOT_DIR}/../debug-root/ ; do \
-                       if test -f $${d}/usr/bin/gdbserver ; then \
-                               install -m 0755 -D $${d}/usr/bin/gdbserver $(TARGET_DIR)/usr/bin/gdbserver ; \
+               for d in $${ARCH_SYSROOT_DIR}/usr $${ARCH_SYSROOT_DIR}/../debug-root/usr $${ARCH_SYSROOT_DIR}/usr/lib ; do \
+                       if test -f $${d}/bin/gdbserver ; then \
+                               install -m 0755 -D $${d}/bin/gdbserver $(TARGET_DIR)/usr/bin/gdbserver ; \
                                gdbserver_found=1 ; \
                                break ; \
                        fi ; \


egrep -v '^#|^$' .config

BR2_HAVE_DOT_CONFIG=y
BR2_i386=y
BR2_x86_pentiumpro=y
BR2_ARCH="i686"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_TUNE="pentiumpro"
BR2_GCC_TARGET_ARCH="pentiumpro"
BR2_WGET="wget --passive-ftp -nd -t 3"
BR2_SVN="svn"
BR2_BZR="bzr"
BR2_GIT="git"
BR2_LOCALFILES="cp"
BR2_SCP="scp"
BR2_SSH="ssh"
BR2_HG="hg"
BR2_ZCAT="gzip -d -c"
BR2_BZCAT="bzcat"
BR2_XZCAT="xzcat"
BR2_TAR_OPTIONS=""
BR2_DL_DIR="$(TOPDIR)/dl"
BR2_HOST_DIR="$(BASE_DIR)/host"
BR2_PRIMARY_SITE=""
BR2_BACKUP_SITE="http://sources.buildroot.net/"
BR2_SOURCEFORGE_MIRROR="kent"
BR2_KERNEL_MIRROR="http://www.kernel.org/pub/"
BR2_GNU_MIRROR="http://ftp.gnu.org/pub/gnu"
BR2_DEBIAN_MIRROR="http://ftp.debian.org"
BR2_JLEVEL=4
BR2_STRIP_strip=y
BR2_OPTIMIZE_S=y
BR2_PACKAGE_OVERRIDE_FILE="$(TOPDIR)/local.mk"
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_X86_201109=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_PREFIX="i686-pc-linux-gnu"
BR2_TOOLCHAIN_EXTERNAL_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y
BR2_LARGEFILE=y
BR2_INET_IPV6=y
BR2_INET_RPC=y
BR2_USE_WCHAR=y
BR2_ENABLE_LOCALE=y
BR2_INSTALL_LIBSTDCPP=y
BR2_TOOLCHAIN_HAS_THREADS=y
BR2_TOOLCHAIN_HAS_THREADS_DEBUG=y
BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED=y
BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS=y
BR2_ENABLE_LOCALE_PURGE=y
BR2_ENABLE_LOCALE_WHITELIST="C en_US"
BR2_USE_MMU=y
BR2_TARGET_OPTIMIZATION="-pipe"
BR2_TARGET_LDFLAGS=""
BR2_TARGET_GENERIC_HOSTNAME="br-x86-glibc"
BR2_TARGET_GENERIC_ISSUE="Welcome to Buildroot"
BR2_ROOTFS_DEVICE_CREATION_STATIC=y
BR2_ROOTFS_DEVICE_TABLE="target/generic/device_table.txt"
BR2_ROOTFS_STATIC_DEVICE_TABLE="target/generic/device_table_dev.txt"
BR2_ROOTFS_SKELETON_DEFAULT=y
BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y
BR2_TARGET_GENERIC_GETTY_BAUDRATE="115200"
BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW=y
BR2_ROOTFS_POST_BUILD_SCRIPT=""
BR2_PACKAGE_BUSYBOX=y
BR2_BUSYBOX_VERSION_1_19_X=y
BR2_BUSYBOX_VERSION="1.19.4"
BR2_PACKAGE_BUSYBOX_CONFIG="package/busybox/busybox-1.19.x.config"
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_BLOCKS=0
BR2_TARGET_ROOTFS_EXT2_INODES=0
BR2_TARGET_ROOTFS_EXT2_RESBLKS=0
BR2_TARGET_ROOTFS_EXT2_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.3"
BR2_LINUX_KERNEL_VERSION="3.3"
BR2_LINUX_KERNEL_PATCH=""
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/x86/linux-3.3.config"
BR2_LINUX_KERNEL_BZIMAGE=y

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Mar 14, 2012 at 11:49 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> When an external toolchain is used, it is very likely that it contains
> a pre-built version of a gdbserver that has the same version as the
> cross-gdb included in the external toolchain. So, we now provide an
> option that allows to copy this pre-built gdbserver to the target.
>
> As the location of the gdbserver in the external toolchain is not
> standardized, we only support the CodeSourcery and Crosstool-NG
> layouts for the moment. Other locations can be added later.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> ?toolchain/gdb/Config.in ? ? ? ? ? ? ? ? ?| ? ?8 ++++++++
> ?toolchain/toolchain-external/ext-tool.mk | ? 14 ++++++++++++++
> ?2 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
> index 8501983..980666b 100644
> --- a/toolchain/gdb/Config.in
> +++ b/toolchain/gdb/Config.in
> @@ -14,10 +14,18 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain"
>
> ?config BR2_PACKAGE_GDB_SERVER
> ? ? ? ?bool "Build gdb server for the Target"
> + ? ? ? depends on !BR2_TOOLCHAIN_EXTERNAL
> ? ? ? ?help
> ? ? ? ? ? ?Build the gdbserver stub to run on the target.
> ? ? ? ? ? ?A full gdb is needed to debug the progam.

With this change, buildroot will no longer present the option of
building gdbserver itself. If you have an external toolchain, it is
now mandatory for it to contain gdbserver (if you want it of course).
I'm not sure if we can always expect this.

In my case, gdb was built by the toolchain, and gdbserver by
buildroot. For me it makes sense to follow your strategy and have
gdbserver built by crosstool-ng instead (and use that as custom
external toolchain).
But maybe there are cases where custom external toolchains do not
contain gdbserver already, and the user would like buildroot to build
it? In that case, we could consider changing the depend line to:
depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM || !BR2_TOOLCHAIN_EXTERNAL

What do you think? Should we cater for this?

Thanks,
Thomas

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Thomas Petazzoni]

Le Wed, 6 Jun 2012 12:16:54 +0200,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> With this change, buildroot will no longer present the option of
> building gdbserver itself. If you have an external toolchain, it is
> now mandatory for it to contain gdbserver (if you want it of course).

Correct.

> I'm not sure if we can always expect this.

I would say it is the case for most external toolchains that exist
today, so it sounds like (at least to me) like a reasonable solution.

> In my case, gdb was built by the toolchain, and gdbserver by
> buildroot. For me it makes sense to follow your strategy and have
> gdbserver built by crosstool-ng instead (and use that as custom
> external toolchain).

Building gdb and gdbserver separately is, IMO, a recipe for disaster.
Even though the gdb remote protocol is supposed to be stable, my
experience is that using a different version for gdb and gdbserver
often causes problems.

> But maybe there are cases where custom external toolchains do not
> contain gdbserver already, and the user would like buildroot to build
> it? In that case, we could consider changing the depend line to:
> depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM || !BR2_TOOLCHAIN_EXTERNAL
> 
> What do you think? Should we cater for this?

Do you have a practical usage for this?

Generally speaking, I'd prefer if we handle really useful use cases,
and to not complexify Buildroot with hypothetic and complex use cases.

Regards,

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

[Buildroot] [PATCH 2/3] debug: provide an option to copy the gdbserver to the target

[Thomas De Schampheleire]

Hi,

On Wed, Jun 6, 2012 at 9:36 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Le Wed, 6 Jun 2012 12:16:54 +0200,
> Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
>
>> With this change, buildroot will no longer present the option of
>> building gdbserver itself. If you have an external toolchain, it is
>> now mandatory for it to contain gdbserver (if you want it of course).
>
> Correct.
>
>> I'm not sure if we can always expect this.
>
> I would say it is the case for most external toolchains that exist
> today, so it sounds like (at least to me) like a reasonable solution.

Ok. If it's the case for most external toolchains, I'm ok with the
current behavior.

>
>> In my case, gdb was built by the toolchain, and gdbserver by
>> buildroot. For me it makes sense to follow your strategy and have
>> gdbserver built by crosstool-ng instead (and use that as custom
>> external toolchain).
>
> Building gdb and gdbserver separately is, IMO, a recipe for disaster.
> Even though the gdb remote protocol is supposed to be stable, my
> experience is that using a different version for gdb and gdbserver
> often causes problems.
>
>> But maybe there are cases where custom external toolchains do not
>> contain gdbserver already, and the user would like buildroot to build
>> it? In that case, we could consider changing the depend line to:
>> depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM || !BR2_TOOLCHAIN_EXTERNAL
>>
>> What do you think? Should we cater for this?
>
> Do you have a practical usage for this?
>

Not now no. I used to build gdbserver in buildroot and ignore the one
from the toolchain, but I have now changed that behavior. It's more
logical and sound, as you say.

So let's keep it the way it is.

Best regards,
Thomas