Using gdb in buildroot

Hi,

This a small respin of two patches that Thomas Petazzoni sent to the list a while back, adding a gdbinit file and updating the manual.

I think these could still go in for 2014.05.

Best regards,
Thomas

This commit slightly improves the external toolchain backend, and the gdb build logic to create a file named $(STAGING_DIR)/usr/share/buildroot/gdbinit which can be used as a gdbinit file using gdb -x option. This allows gdb to automatically use the proper sysroot to find libraries.

The initial insight for this patch comes from the report of Oded Hanson <[email protected]>, who found an issue with the Eclipse Buildroot plugin, which was setting a solib-path in gdb, but not a sysroot. Setting a solib-path was enough to find shared libraries, but not the dynamic linker. And since Eclipse doesn't allow to set the sysroot in any other way than giving a gdbinit file, it makes sense to have Buildroot generate a gdbinit file (which can be used in other situations than Eclipse).

To achieve this, this commit introduces a gen_gdbinit_file helper in toolchain/helpers.mk, and uses it for the internal toolchain and external toolchain backends.

---
 package/gdb/gdb.mk                                 | 2 ++
 toolchain/helpers.mk                               | 7 +++++++
 toolchain/toolchain-external/toolchain-external.mk | 7 +++++++
 3 files changed, 16 insertions(+)

@@ -126,5 +126,7 @@ endef
 
 HOST_GDB_POST_INSTALL_HOOKS += HOST_GDB_ADD_SYMLINK
 
+HOST_GDB_POST_INSTALL_HOOKS += gen_gdbinit_file
+
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))

@@ -355,3 +355,10 @@ check_unusable_toolchain = \
 		echo "such as Buildroot." ; \
 		exit 1 ; \
 	fi
+
+#
+# Generate gdbinit file for use with Buildroot
+#
+gen_gdbinit_file = \
+	mkdir -p $(STAGING_DIR)/usr/share/buildroot/ ; \
+	echo "set sysroot $(STAGING_DIR)" > $(STAGING_DIR)/usr/share/buildroot/gdbinit

@@ -651,6 +651,12 @@ define TOOLCHAIN_EXTERNAL_SANITIZE_KERNE
 		-e 's@#(ifndef|define|endif[ \t]*/[*])[ \t]*_UAPI@#\1 @'
 endef
 
+define TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT
+	if test -f $(TARGET_CROSS)gdb ; then \
+		$(call gen_gdbinit_file) ; \
+	fi
+endef
+
 # Even though we're installing things in both the staging, the host
 # and the target directory, we do everything within the
 # install-staging step, arbitrarily.

@@ -659,6 +665,7 @@ define TOOLCHAIN_EXTERNAL_INSTALL_STAGIN
 	$(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC)
 	$(TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT)
 	$(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER)
+	$(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
 endef
 
 $(eval $(generic-package))

---
v2: some rewording, taking into account the comment of Baruch, also clarifying the example command (typically foo is not in the buildroot root).

 docs/manual/advanced.txt                 |   2 +
 docs/manual/using-buildroot-debugger.txt |  49 +++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 docs/manual/using-buildroot-debugger.txt

@@ -5,6 +5,8 @@
 
 include::using-buildroot-toolchain.txt[]
 
+include::using-buildroot-debugger.txt[]
+
 include::ccache-support.txt[]
 
 include::download-location.txt[]

Dear Thomas De Schampheleire,

Thanks for this update! However, it looks like you haven't preserved the authorship on these patches, even though your modifications are apparently relatively small. Is that intended?

Thanks!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

hi Thomas,

Thomas Petazzoni <[email protected]> schreef:

I'm not sure what you mean.I left your original sob line and added mine below. Isn't this leaving the authorship with you?
I thought this is the right strategy when sending even slightly modified patches of someone else. If this is incorrect, please clarify and accept my apologies...

Best regards,
Thomas

Thomas,

On 2014-05-03 22:18 +0200, Thomas De Schampheleire spake thusly:

What Thomas meant, you forgot to commit with:
git commit --author='Thomas P. <...@...>'

when you adopted the patch, hence you are now credited as the author of that patch, not the other Thomas.

That's a mistake that is easily done when using 'patch -p1 <file.patch'.

If you had been using 'pwclient am PATH-ID' instead, it would have kept the authorship.

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'