[Buildroot] [PATCH 0 of 2 v4] Using gdb in buildroot
From: Thomas De Schampheleire <hidden>
Date: 2014-05-05 09:25:49
Sorry for the mess. This time a proper v4, addressing Samuel's comments. Best regards, Thomas
4 messages, 2 authors, 2014-05-05 · open the first message on its own page
From: Thomas De Schampheleire <hidden>
Date: 2014-05-05 09:25:49
Sorry for the mess. This time a proper v4, addressing Samuel's comments. Best regards, Thomas
From: Thomas De Schampheleire <hidden>
Date: 2014-05-05 09:25:50
From: Thomas Petazzoni <redacted> 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 [off-list ref], 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. Signed-off-by: Thomas Petazzoni <redacted> [ThomasDS: minor updates in commit message] Signed-off-by: Thomas De Schampheleire <redacted> --- v4: no changes 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(+)
diff --git a/package/gdb/gdb.mk b/package/gdb/gdb.mk
--- a/package/gdb/gdb.mk
+++ b/package/gdb/gdb.mk@@ -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))
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk@@ -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
diff --git a/toolchain/toolchain-external/toolchain-external.mk b/toolchain/toolchain-external/toolchain-external.mk
--- a/toolchain/toolchain-external/toolchain-external.mk
+++ b/toolchain/toolchain-external/toolchain-external.mk@@ -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))
From: Thomas De Schampheleire <hidden>
Date: 2014-05-05 09:25:51
From: Thomas Petazzoni <redacted> Signed-off-by: Thomas Petazzoni <redacted> [ThomasDS: some rewording, add <buildroot> path prefix in example] Signed-off-by: Thomas De Schampheleire <redacted> --- v4: add 'target remote' command line (Samuel) 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 | 53 +++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 0 deletions(-) create mode 100644 docs/manual/using-buildroot-debugger.txt
diff --git a/docs/manual/advanced.txt b/docs/manual/advanced.txt
--- a/docs/manual/advanced.txt
+++ b/docs/manual/advanced.txt@@ -5,6 +5,8 @@ include::using-buildroot-toolchain.txt[] +include::using-buildroot-debugger.txt[] + include::ccache-support.txt[] include::download-location.txt[]
diff --git a/docs/manual/using-buildroot-debugger.txt b/docs/manual/using-buildroot-debugger.txt
new file mode 100644
--- /dev/null
+++ b/docs/manual/using-buildroot-debugger.txt@@ -0,0 +1,53 @@ +// -*- 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 +---------------------------- + +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 +---------------------------- + +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. + +Finally, to connect to the target from the cross gdb: + +---------------------------- +(gdb) target remote <target ip address>:2345 +----------------------------
From: Peter Korsgaard <hidden>
Date: 2014-05-05 11:45:50
quoted
quoted
quoted
quoted
"Thomas" == Thomas De Schampheleire [off-list ref] writes:
> Sorry for the mess. This time a proper v4, addressing Samuel's comments. Committed both, thanks. -- Bye, Peter Korsgaard