Pull request for branch for-2011.11/debugging-improvements

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

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.

---
 Config.in |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

index 2002996..e07e52f 100644
@@ -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

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.

---
 toolchain/gdb/Config.in                  |    8 ++++++++
 toolchain/toolchain-external/ext-tool.mk |   14 ++++++++++++++
 2 files changed, 22 insertions(+), 0 deletions(-)

index 8501983..980666b 100644
@@ -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

index 01ab91f..6e9686c 100644
@@ -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

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

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(-)

index a45603a..7101e1f 100644
@@ -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

Hi Thomas,

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

Le Wed, 6 Jun 2012 12:16:54 +0200,
Thomas De Schampheleire <[email protected]> a ?crit :

Correct.

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.

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.

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

Hi,

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

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

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.

---
 Config.in |   32 ++++++++++++++++++++------------
 1 files changed, 20 insertions(+), 12 deletions(-)

index e07e52f..2edeae2 100644
@@ -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

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