[Buildroot] [PATCH 0 of 2 v2] Using gdb in buildroot

[Buildroot] [PATCH 0 of 2 v2] Using gdb in buildroot

[Thomas De Schampheleire]

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

[Buildroot] [PATCH 1 of 2 v2] toolchain: generate a gdbinit file

[Thomas De Schampheleire]

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 <OHanson@xsightsys.com>, 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 <thomas.petazzoni@free-electrons.com>
[ThomasDS: minor updates in commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

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

[Buildroot] [PATCH 2 of 2 v2] docs/manual: document how to use the cross debugger

[Thomas De Schampheleire]

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[ThomasDS: some rewording, add <buildroot> path prefix in example]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

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

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,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
+----------------------------
+
+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.
+

[Buildroot] [PATCH 0 of 2 v2] Using gdb in buildroot

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sat, 03 May 2014 16:09:51 +0200, Thomas De Schampheleire wrote:

> 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.

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

[Buildroot] [PATCH 0 of 2 v2] Using gdb in buildroot

[Thomas De Schampheleire]

hi Thomas,

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
>Dear Thomas De Schampheleire,
>
>On Sat, 03 May 2014 16:09:51 +0200, Thomas De Schampheleire wrote:
>
>> 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.
>
>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?

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

[Buildroot] [PATCH 0 of 2 v2] Using gdb in buildroot

[Yann E. MORIN]

Thomas,

On 2014-05-03 22:18 +0200, Thomas De Schampheleire spake thusly:
> hi Thomas,
> 
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> schreef:
> >Dear Thomas De Schampheleire,
> >
> >On Sat, 03 May 2014 16:09:51 +0200, Thomas De Schampheleire wrote:
> >
> >> 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.
> >
> >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?
> 
> 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...

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.  |
'------------------------------^-------^------------------^--------------------'