[Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option

[Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option

[Evgeniy Didin]

Some prebuilt toolchains provide full gdb debugger for a target as
well as gdbserver. Lets add separate option for gdb the same way as
it was done for gdbserver. With this change there will be no need
to build gdb package, this will reduce build time.

Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot at synopsys.com
---
 toolchain/toolchain-external/Config.in             |  7 ++++++
 .../toolchain-external/pkg-toolchain-external.mk   | 25 ++++++++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/toolchain/toolchain-external/Config.in b/toolchain/toolchain-external/Config.in
index 128bea257e..b20ce93100 100644
--- a/toolchain/toolchain-external/Config.in
+++ b/toolchain/toolchain-external/Config.in
@@ -162,4 +162,11 @@ config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
 	  Copy the gdbserver provided by the external toolchain to the
 	  target.
 
+config BR2_TOOLCHAIN_EXTERNAL_GDB_COPY
+	bool "Copy gdb to the Target"
+	depends on BR2_TOOLCHAIN_EXTERNAL
+	help
+	  Copy the gdb debugger provided by the external toolchain 
+	  to the target.
+
 endif # BR2_TOOLCHAIN_EXTERNAL
diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index 1c43409514..c400b46590 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -430,6 +430,30 @@ define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER
 endef
 endif
 
+ifeq ($(BR2_TOOLCHAIN_EXTERNAL_GDB_COPY),y)
+define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDB
+
+	$(Q)$(call MESSAGE,"Copying gdb")
+	$(Q)ARCH_SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
+	ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
+	gdb_found=0 ; \
+	for d in $${ARCH_SYSROOT_DIR}/usr \
+		 $${ARCH_SYSROOT_DIR}/../debug-root/usr \
+		 $${ARCH_SYSROOT_DIR}/usr/$${ARCH_LIB_DIR} \
+		 $(TOOLCHAIN_EXTERNAL_INSTALL_DIR); do \
+		if test -f $${d}/bin/gdb ; then \
+			install -m 0755 -D $${d}/bin/gdb $(TARGET_DIR)/usr/bin/gdb ; \
+			gdb_found=1 ; \
+			break ; \
+		fi ; \
+	done ; \
+	if [ $${gdb_found} -eq 0 ] ; then \
+		echo "Could not find gdb in external toolchain" ; \
+		exit 1 ; \
+	fi
+endef
+endif
+
 define TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS
 	$(Q)SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC))" ; \
 	ARCH_SYSROOT_DIR="$(call toolchain_find_sysroot,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
@@ -591,6 +615,7 @@ define $(2)_INSTALL_TARGET_CMDS
 	$$(TOOLCHAIN_EXTERNAL_CREATE_TARGET_LIB_SYMLINK)
 	$$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS)
 	$$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER)
+        $$(TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDB)
 	$$(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)
 endef
 
-- 
2.16.2

[Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option

[Thomas Petazzoni]

Hello,

On Mon, 18 Nov 2019 11:00:47 +0300
Evgeniy Didin <Evgeniy.Didin@synopsys.com> wrote:

> Some prebuilt toolchains provide full gdb debugger for a target as
> well as gdbserver. Lets add separate option for gdb the same way as
> it was done for gdbserver. With this change there will be no need
> to build gdb package, this will reduce build time.
> 
> Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: arc-buildroot at synopsys.com

Thanks for your contribution and proposal. However, I'm wondering if
this really works properly in the general case. Indeed, gdb is often
linked against additional libraries: ncurses, expat, python, zlib,
lzma, etc.

Here you are only copying the gdb binary itself, but not the libraries
it might depend on. But even if you were copying those libraries, they
would potentially conflict with the ones built by Buildroot.

So I'm not sure if there's really a good way to re-use a gdb built by
an external toolchain.

In your specific case, is the gdb binary statically linked ? Or at
least statically linked against all libraries except the C library ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option

[Evgeniy Didin]

Hi Thomas,

Using prebuilt toolchain besides the speedup of build has another advantage - in most cases that toolchain was well tested
and guaranteed to work stable. And without copything the prebuilt GDB debugger to target we need to build it from sources,
which version is defined in package/gdb and most likely is different to prebuilt toolchain version. gdbserver ver. XXX may not be
able to work with GDB ver. YYY.

In our case we have dynamically linked minimalistic GDB with only Libc components dependencies:
--------------------------------8<--------------------------------
 $ arc-linux-objdump  -hx gdb | grep  NEEDED
  NEEDED               libdl.so.2
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
-------------------------------->8--------------------------------

In linaro/arm/mips toolchains there is no prebuilt GDB debugger,
so I guess we should add additional  conditional "depends on BR2_arc".
Will it be acceptable?


Best regards,
Evgeniy Didin

________________________________
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Sent: Monday, November 18, 2019 11:11 AM
To: Evgeniy Didin <didin@synopsys.com>
Cc: buildroot at busybox.net <buildroot@busybox.net>; arc-buildroot at synopsys.com <arc-buildroot@synopsys.com>
Subject: Re: [PATCH] toolchain-external: Introduce gdb_copy option

Hello,

On Mon, 18 Nov 2019 11:00:47 +0300
Evgeniy Didin <Evgeniy.Didin@synopsys.com> wrote:

> Some prebuilt toolchains provide full gdb debugger for a target as
> well as gdbserver. Lets add separate option for gdb the same way as
> it was done for gdbserver. With this change there will be no need
> to build gdb package, this will reduce build time.
>
> Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: arc-buildroot at synopsys.com

Thanks for your contribution and proposal. However, I'm wondering if
this really works properly in the general case. Indeed, gdb is often
linked against additional libraries: ncurses, expat, python, zlib,
lzma, etc.

Here you are only copying the gdb binary itself, but not the libraries
it might depend on. But even if you were copying those libraries, they
would potentially conflict with the ones built by Buildroot.

So I'm not sure if there's really a good way to re-use a gdb built by
an external toolchain.

In your specific case, is the gdb binary statically linked ? Or at
least statically linked against all libraries except the C library ?

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://urldefense.proofpoint.com/v2/url?u=https-3A__bootlin.com&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=vQk-RIbjwN0zvlwiMSpq3LYUTNf7Gqc4ujhosYITtAw&m=SXU3CLEFC_hZpwD_KK6WpxW8OHqUqDky3Xlk5lP1YnE&s=mzhhB4FhsPlQsOUtfTztvQS-aUwyPOSc36awKfu1hpU&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191118/ca398614/attachment.html>

[Buildroot] [PATCH] toolchain-external: Introduce gdb_copy option

[Thomas Petazzoni]

Hello Evgeniy,

Top-posting on most open-source mailing list is not considered to be a
good practice. If possible, you should try to do bottom posting. Thanks!

On Mon, 18 Nov 2019 12:01:56 +0000
Evgeniy Didin <Evgeniy.Didin@synopsys.com> wrote:

> Using prebuilt toolchain besides the speedup of build has another advantage - in most cases that toolchain was well tested
> and guaranteed to work stable.

True.

> And without copything the prebuilt GDB debugger to target we need to build it from sources,
> which version is defined in package/gdb and most likely is different to prebuilt toolchain version. gdbserver ver. XXX may not be
> able to work with GDB ver. YYY.

Wait, this argument does not make sense: your patch is about copying
gdb to the target, so it is completely unrelated to gdbserver.

You can already today use the cross-gdb of the external toolchain
together with the gdbserver of the external toolchain: it is precisely
because there is often some kind of version dependency between both
that we have a Buildroot option to copy the toolchain-provided
gdbserver to the target.

However your patch is about copying the full *target* gdb to the target
filesystem, which again is completely unrelated to gdbserver.

> In our case we have dynamically linked minimalistic GDB with only Libc components dependencies:
> --------------------------------8<--------------------------------
>  $ arc-linux-objdump  -hx gdb | grep  NEEDED
>   NEEDED               libdl.so.2
>   NEEDED               libstdc++.so.6
>   NEEDED               libm.so.6
>   NEEDED               libgcc_s.so.1
>   NEEDED               libc.so.6

This is true today for your specific toolchain, but it is very possible
that in the future you will enable support for ncurses/readline, for
python, for expat, or other features. And then it will simply not work.

> In linaro/arm/mips toolchains there is no prebuilt GDB debugger,
> so I guess we should add additional  conditional "depends on BR2_arc".
> Will it be acceptable?

I think I would only find it acceptable if there was a check that the
target gdb provided by the toolchain only had dependencies on the C
library (libdl, libstdc++, libm, libc, etc.), and no other dependencies.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com