Using gdb in buildroot
PATCH v3 1/1 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.
In v2, the authorship of Thomas Petazzoni got lost, unintentionally. This was the first time I'm resending someone else's patches, and foolishly thought that the Signed-off-by line would be the key to authorship. Note also that I'm not using git but Mercurial. When applying the mbox from patchwork in my hg repo, the author is correctly shown as ThomasP, but as I'm sending the patch in non-hg (plain) mode, that piece of information is lost. It seems I have to add an explicit 'From: foo <bar>' line in the commit message to get git to recognize the correct author.
Best regards,
Thomas
PATCH v3 1/1 toolchain: generate a gdbinit file
From: Thomas Petazzoni <[email protected]>
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.
---
v3: retain proper authorship of ThomasP
v2: update commit message
package/gdb/gdb.mk | 2 ++ toolchain/helpers.mk | 7 +++++++ toolchain/toolchain-external/toolchain-external.mk | 7 +++++++ 3 files changed, 16 insertions(+)
package/gdb/gdb.mk +2 -0
@@ -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))
toolchain/helpers.mk +7 -0
@@ -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
toolchain/toolchain-external/toolchain-external.mk +7 -0
@@ -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))
PATCH v3 1/1 docs/manual: document how to use the cross debugger
In reply to Thomas De SchampheleireFrom: Thomas Petazzoni <[email protected]>
---
v3: retain proper authorship of ThomasP
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
docs/manual/advanced.txt +2 -0
@@ -5,6 +5,8 @@ include::using-buildroot-toolchain.txt[] +include::using-buildroot-debugger.txt[] + include::ccache-support.txt[] include::download-location.txt[]
docs/manual/using-buildroot-debugger.txt new file +48 -0
48 lines not on this page · raw message
PATCH v3 1/1 docs/manual: document how to use the cross debugger
Hi Thomas?, all,
Quoted 64 lines · Thomas De Schampheleire
From: Thomas Petazzoni <[email protected]>
Signed-off-by Thomas Petazzoni <[email protected]>[ThomasDS: some rewording, add <buildroot> path prefix in example]Signed-off-by Thomas De Schampheleire <[email protected]>---
v3: retain proper authorship of ThomasP
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.txtdocs/manual/advanced.txt +2
-0@@ -5,6 +5,8 @@ include::using-buildroot-toolchain.txt[] +include::using-buildroot-debugger.txt[] + include::ccache-support.txt[] include::download-location.txt[]docs/manual/using-buildroot-debugger.txt new file +30
-0@@ -0,0 +1,48 @@ +// -*- mode:doc; -*- +// vim: set syntax=asciidoc: + +=== Using +gdb+ in Buildroot + +Buildroot allows to do cross-debugging, where the debugger runs on the +build machine and communicates with +gdbserver+ on the target to +control the execution of the program. + +To achieve this: + +* If you are using an _internal toolchain_ (built by Buildroot), you + must enable +BR2_PACKAGE_HOST_GDB+, +BR2_PACKAGE_GDB+ and + +BR2_PACKAGE_GDB_SERVER+. This ensures that both the cross gdb and + gdbserver get built, and that gdbserver gets installed to your target. + +* If you are using an _external toolchain_, you should enable + +BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY+, which will copy the + gdbserver included with the external toolchain to the target. If your + external toolchain does not have a cross gdb or gdbserver, it is also + possible to let Buildroot build them, by enabling the same options as + for the _internal toolchain backend_. + +Now, to start debugging a program called +foo+, you should run on the +target: + +---------------------------- +gdbserver :2345 foo +---------------------------- +
docs/manual/using-buildroot-debugger.txt line 40
Quoted 10 lines
docs/manual/using-buildroot-debugger.txt new file +10
-0+This will cause +gdbserver+ to listen on TCP port 2345 for a connection +from the cross gdb. + +Then, on the host, you should start the cross gdb using the following +command line: + +---------------------------- +<buildroot>/output/host/usr/bin/<tuple>-gdb -x <buildroot>/output/staging/usr/share/buildroot/gdbinit foo +---------------------------- +
From here, one still needs to tell gdb where is the target by running:
---
gdb$ target remote <target ip address>:2345
---
Might be worthwhile to help people who begins with remote debugging. ;)
Quoted 8 lines
docs/manual/using-buildroot-debugger.txt new file +8
-0+Of course, +foo+ must be available in the current directory, built +with debugging symbols. Typically you start this command from the +directory where +foo+ is built (and not from +output/target/+ as the +binaries in that directory are stripped). + +The +<buildroot>/output/staging/usr/share/buildroot/gdbinit+ file will tell the +cross gdb where to find the libraries of the target. +
Quoted 4 lines
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Regards,
Signature · 1 line
Samuel