[Buildroot] [PATCH v2 0/2] Make remote debugging easier

[Buildroot] [PATCH v2 0/2] Make remote debugging easier

[unixmania at gmail.com]

From: Carlos Santos <unixmania@gmail.com>

Patch 1 moves binaries stripping to the rootfs creation instead of in
target-finalize. This allows us to find the non-stripped executables
under TARGET_DIR, rather than searching inside the build directory.

Patch 2 updates the gdbinit file to set sysroot to TARGET_DIR.

Carlos Santos (2):
  Strip binaries in the rootfs creation instead of in target-finalize
  toolchain: install gdbinit under TARGET_DIR

 Makefile                                      | 34 -----------------
 docs/manual/quickstart.txt                    |  5 ++-
 docs/manual/using-buildroot-debugger.txt      | 11 ++++--
 fs/common.mk                                  | 37 ++++++++++++++++++-
 toolchain/helpers.mk                          |  4 +-
 .../pkg-toolchain-external.mk                 |  4 +-
 6 files changed, 50 insertions(+), 45 deletions(-)

-- 
2.18.1

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[unixmania at gmail.com]

From: Carlos Santos <unixmania@gmail.com>

Since commit 118534fe54 the root filesystem image is generated from a
temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
only.

This allows us to easily find the non-stripped executables to debug with
gdbserver, as they are at the same relative path in TARGET_DIR as in the
target device, rather than searching inside the build directory.

Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386

Signed-off-by: Carlos Santos <unixmania@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
CC: Ciro Santilli <ciro.santilli@gmail.com>
---
Changes v1->v2:
- Strip before running the fakeroot script, as suggested by Arnout
  Vandecappelle
- Change commit message accordingly. Removed paragraph about setting
  sysroot to TARGET_DIR in gdb, which is done in the next commit.
---
 Makefile     | 34 ----------------------------------
 fs/common.mk | 36 +++++++++++++++++++++++++++++++++++-
 2 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/Makefile b/Makefile
index ecaae13846..57314e5f1d 100644
--- a/Makefile
+++ b/Makefile
@@ -614,38 +614,6 @@ RSYNC_VCS_EXCLUSIONS = \
 	--exclude .svn --exclude .git --exclude .hg --exclude .bzr \
 	--exclude CVS
 
-# When stripping, obey to BR2_STRIP_EXCLUDE_DIRS and
-# BR2_STRIP_EXCLUDE_FILES
-STRIP_FIND_COMMON_CMD = \
-	find $(TARGET_DIR) \
-	$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS)), \
-		\( $(call finddirclauses,$(TARGET_DIR),$(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS))) \) \
-		-prune -o \
-	) \
-	$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES)), \
-		-not \( $(call findfileclauses,$(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) )
-
-# Regular stripping for everything, except libpthread, ld-*.so and
-# kernel modules:
-# - libpthread.so: a non-stripped libpthread shared library is needed for
-#   proper debugging of pthread programs using gdb.
-# - ld.so: a non-stripped dynamic linker library is needed for valgrind
-# - kernel modules (*.ko): do not function properly when stripped like normal
-#   applications and libraries. Normally kernel modules are already excluded
-#   by the executable permission check, so the explicit exclusion is only
-#   done for kernel modules with incorrect permissions.
-STRIP_FIND_CMD = \
-	$(STRIP_FIND_COMMON_CMD) \
-	-type f \( -perm /111 -o -name '*.so*' \) \
-	-not \( $(call findfileclauses,libpthread*.so* ld-*.so* *.ko) \) \
-	-print0
-
-# Special stripping (only debugging symbols) for libpthread and ld-*.so.
-STRIP_FIND_SPECIAL_LIBS_CMD = \
-	$(STRIP_FIND_COMMON_CMD) \
-	\( -name 'ld-*.so*' -o -name 'libpthread*.so*' \) \
-	-print0
-
 ifeq ($(BR2_ECLIPSE_REGISTER),y)
 define TOOLCHAIN_ECLIPSE_REGISTER
 	./support/scripts/eclipse-register-toolchain `readlink -f $(O)` \
@@ -761,8 +729,6 @@ endif
 	rm -rf $(TARGET_DIR)/usr/doc $(TARGET_DIR)/usr/share/doc
 	rm -rf $(TARGET_DIR)/usr/share/gtk-doc
 	rmdir $(TARGET_DIR)/usr/share 2>/dev/null || true
-	$(STRIP_FIND_CMD) | xargs -0 $(STRIPCMD) 2>/dev/null || true
-	$(STRIP_FIND_SPECIAL_LIBS_CMD) | xargs -0 -r $(STRIPCMD) $(STRIP_STRIP_DEBUG) 2>/dev/null || true
 
 	test -f $(TARGET_DIR)/etc/ld.so.conf && \
 		{ echo "ERROR: we shouldn't have a /etc/ld.so.conf file"; exit 1; } || true
diff --git a/fs/common.mk b/fs/common.mk
index 842ea924a5..caa7825cbb 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -61,6 +61,38 @@ ROOTFS_COMMON_FINAL_RECURSIVE_DEPENDENCIES = $(sort \
 	) \
 	$(ROOTFS_COMMON_FINAL_RECURSIVE_DEPENDENCIES__X))
 
+# When stripping, obey to BR2_STRIP_EXCLUDE_DIRS and
+# BR2_STRIP_EXCLUDE_FILES
+STRIP_FIND_COMMON_CMD = \
+	find $(TARGET_DIR) \
+	$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS)), \
+		\( $(call finddirclauses,$(TARGET_DIR),$(call qstrip,$(BR2_STRIP_EXCLUDE_DIRS))) \) \
+		-prune -o \
+	) \
+	$(if $(call qstrip,$(BR2_STRIP_EXCLUDE_FILES)), \
+		-not \( $(call findfileclauses,$(call qstrip,$(BR2_STRIP_EXCLUDE_FILES))) \) )
+
+# Regular stripping for everything, except libpthread, ld-*.so and
+# kernel modules:
+# - libpthread.so: a non-stripped libpthread shared library is needed for
+#   proper debugging of pthread programs using gdb.
+# - ld.so: a non-stripped dynamic linker library is needed for valgrind
+# - kernel modules (*.ko): do not function properly when stripped like normal
+#   applications and libraries. Normally kernel modules are already excluded
+#   by the executable permission check, so the explicit exclusion is only
+#   done for kernel modules with incorrect permissions.
+STRIP_FIND_CMD = \
+	$(STRIP_FIND_COMMON_CMD) \
+	-type f \( -perm /111 -o -name '*.so*' \) \
+	-not \( $(call findfileclauses,libpthread*.so* ld-*.so* *.ko) \) \
+	-print0
+
+# Special stripping (only debugging symbols) for libpthread and ld-*.so.
+STRIP_FIND_SPECIAL_LIBS_CMD = \
+	$(STRIP_FIND_COMMON_CMD) \
+	\( -name 'ld-*.so*' -o -name 'libpthread*.so*' \) \
+	-print0
+
 .PHONY: rootfs-common
 rootfs-common: $(ROOTFS_COMMON_DEPENDENCIES) target-finalize
 	@$(call MESSAGE,"Generating root filesystems common tables")
@@ -157,9 +189,11 @@ $$(BINARIES_DIR)/$$(ROOTFS_$(2)_FINAL_IMAGE_NAME): $$(ROOTFS_$(2)_DEPENDENCIES)
 		$$(BASE_TARGET_DIR)/ \
 		$$(TARGET_DIR)
 
+	$$(STRIP_FIND_CMD) | xargs -0 $$(STRIPCMD) 2>/dev/null || true
+	$$(STRIP_FIND_SPECIAL_LIBS_CMD) | xargs -0 -r $$(STRIPCMD) $$(STRIP_STRIP_DEBUG) 2>/dev/null || true
+
 	echo '#!/bin/sh' > $$(FAKEROOT_SCRIPT)
 	echo "set -e" >> $$(FAKEROOT_SCRIPT)
-
 	echo "chown -h -R 0:0 $$(TARGET_DIR)" >> $$(FAKEROOT_SCRIPT)
 	PATH=$$(BR_PATH) $$(TOPDIR)/support/scripts/mkusers $$(ROOTFS_FULL_USERS_TABLE) $$(TARGET_DIR) >> $$(FAKEROOT_SCRIPT)
 	echo "$$(HOST_DIR)/bin/makedevs -d $$(ROOTFS_FULL_DEVICES_TABLE) $$(TARGET_DIR)" >> $$(FAKEROOT_SCRIPT)
-- 
2.18.1

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Thomas Petazzoni]

On Mon, 30 Sep 2019 22:36:53 -0300
unixmania at gmail.com wrote:

> From: Carlos Santos <unixmania@gmail.com>
> 
> Since commit 118534fe54 the root filesystem image is generated from a
> temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
> only.
> 
> This allows us to easily find the non-stripped executables to debug with
> gdbserver, as they are at the same relative path in TARGET_DIR as in the
> target device, rather than searching inside the build directory.
> 
> Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386
> 
> Signed-off-by: Carlos Santos <unixmania@gmail.com>
> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

I see Arnout reviewed-by this, and while I understand the goal, I am
not sure this is the real direction/solution we want for this problem.
I believe the real solution we have been talking about for a long time
is to install everything in STAGING_DIR (not just libraries). This way,
unstripped binaries with debugging symbols with all be in STAGING_DIR.

To me, the change being proposed here makes TARGET_DIR really different
from what ends up in the final rootfs image. While we admittely already
have a few differences, I personally like to keep the idea of
TARGET_DIR being really what's on the target root filesystem, with as
few differences as possible.

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

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Carlos Santos]

On Tue, Oct 1, 2019 at 3:52 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> On Mon, 30 Sep 2019 22:36:53 -0300
> unixmania at gmail.com wrote:
>
> > From: Carlos Santos <unixmania@gmail.com>
> >
> > Since commit 118534fe54 the root filesystem image is generated from a
> > temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
> > only.
> >
> > This allows us to easily find the non-stripped executables to debug with
> > gdbserver, as they are at the same relative path in TARGET_DIR as in the
> > target device, rather than searching inside the build directory.
> >
> > Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386
> >
> > Signed-off-by: Carlos Santos <unixmania@gmail.com>
> > Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
>
> I see Arnout reviewed-by this, and while I understand the goal, I am
> not sure this is the real direction/solution we want for this problem.
> I believe the real solution we have been talking about for a long time
> is to install everything in STAGING_DIR (not just libraries). This way,
> unstripped binaries with debugging symbols with all be in STAGING_DIR.
>
> To me, the change being proposed here makes TARGET_DIR really different
> from what ends up in the final rootfs image. While we admittely already
> have a few differences, I personally like to keep the idea of
> TARGET_DIR being really what's on the target root filesystem, with as
> few differences as possible.

We could make it optional, keeping the the current behavior by default.

-- 
Carlos Santos <unixmania@gmail.com>

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Yann E. MORIN]

Thomas, Carlos, Arnout, All,

On 2019-10-01 08:52 +0200, Thomas Petazzoni spake thusly:
> On Mon, 30 Sep 2019 22:36:53 -0300
> unixmania at gmail.com wrote:
> 
> > From: Carlos Santos <unixmania@gmail.com>
> > 
> > Since commit 118534fe54 the root filesystem image is generated from a
> > temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
> > only.
> > 
> > This allows us to easily find the non-stripped executables to debug with
> > gdbserver, as they are at the same relative path in TARGET_DIR as in the
> > target device, rather than searching inside the build directory.
> > 
> > Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386
> > 
> > Signed-off-by: Carlos Santos <unixmania@gmail.com>
> > Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> 
> I see Arnout reviewed-by this, and while I understand the goal, I am
> not sure this is the real direction/solution we want for this problem.
> I believe the real solution we have been talking about for a long time
> is to install everything in STAGING_DIR (not just libraries). This way,
> unstripped binaries with debugging symbols with all be in STAGING_DIR.

I agree with Thomas here.

The dichotomy between staging/ and target/ has no raison-d'?tre nowadays.

The idea would be to ensure that all packages install in staging/,
always. Then, identify packages that have different commands for target/
and staging/ and make them identical. Finally, remove the target install
commands, and genreate it as a copy of staging at the beginning of the
target-finalize step.

Yes, the real patches will be a bit more gory than the ideal view above.
But except for some special snowflakes (qt5, I'm looking at you), it
should be fairly straghtforward...

> To me, the change being proposed here makes TARGET_DIR really different
> from what ends up in the final rootfs image. While we admittely already
> have a few differences, I personally like to keep the idea of
> TARGET_DIR being really what's on the target root filesystem, with as
> few differences as possible.

I beg to slightly disagree here, and with a much more controversial view
on the topic: we should just get rid of target/ altogether. The only
valid artefacts we generates are the images in images/

But that one is definitely not on the table. ;-)

Regards,
Yann E. MORIN.

> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Thomas Petazzoni]

Hello Carlos,

On Mon, 30 Sep 2019 22:36:53 -0300
unixmania at gmail.com wrote:

> From: Carlos Santos <unixmania@gmail.com>
> 
> Since commit 118534fe54 the root filesystem image is generated from a
> temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
> only.
> 
> This allows us to easily find the non-stripped executables to debug with
> gdbserver, as they are at the same relative path in TARGET_DIR as in the
> target device, rather than searching inside the build directory.
> 
> Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386
> 
> Signed-off-by: Carlos Santos <unixmania@gmail.com>
> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> CC: Ciro Santilli <ciro.santilli@gmail.com>
> ---
> Changes v1->v2:
> - Strip before running the fakeroot script, as suggested by Arnout
>   Vandecappelle
> - Change commit message accordingly. Removed paragraph about setting
>   sysroot to TARGET_DIR in gdb, which is done in the next commit.
> ---
>  Makefile     | 34 ----------------------------------
>  fs/common.mk | 36 +++++++++++++++++++++++++++++++++++-
>  2 files changed, 35 insertions(+), 35 deletions(-)

There's been feedback from both Yann and me on this patch, and both of
us think this is not the approach we want to take. Instead, we'd rather
see everything installed to STAGING_DIR as the way of fixing the
original issue.

So I've marked both patches as Rejected in patchwork. Of course, if
other people disagree with this decision, we can always revisit and
rediscuss the matter.

Thanks!

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

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Carlos Santos]

On Mon, Apr 13, 2020 at 11:02 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Carlos,
>
> On Mon, 30 Sep 2019 22:36:53 -0300
> unixmania at gmail.com wrote:
>
> > From: Carlos Santos <unixmania@gmail.com>
> >
> > Since commit 118534fe54 the root filesystem image is generated from a
> > temporary copy of TARGET_DIR, so we can strip the binaries in the copy,
> > only.
> >
> > This allows us to easily find the non-stripped executables to debug with
> > gdbserver, as they are at the same relative path in TARGET_DIR as in the
> > target device, rather than searching inside the build directory.
> >
> > Fixes: https://bugs.busybox.net/show_bug.cgi?id=10386
> >
> > Signed-off-by: Carlos Santos <unixmania@gmail.com>
> > Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> > ---
> > CC: Ciro Santilli <ciro.santilli@gmail.com>
> > ---
> > Changes v1->v2:
> > - Strip before running the fakeroot script, as suggested by Arnout
> >   Vandecappelle
> > - Change commit message accordingly. Removed paragraph about setting
> >   sysroot to TARGET_DIR in gdb, which is done in the next commit.
> > ---
> >  Makefile     | 34 ----------------------------------
> >  fs/common.mk | 36 +++++++++++++++++++++++++++++++++++-
> >  2 files changed, 35 insertions(+), 35 deletions(-)
>
> There's been feedback from both Yann and me on this patch, and both of
> us think this is not the approach we want to take. Instead, we'd rather
> see everything installed to STAGING_DIR as the way of fixing the
> original issue.
>
> So I've marked both patches as Rejected in patchwork. Of course, if
> other people disagree with this decision, we can always revisit and
> rediscuss the matter.

Just to remind you, the problem was reported two and a half years ago
and the situation is still the same. Perfect is the enemy of good and
later easily becomes never. Anyway, your project, your rules.

-- 
Carlos Santos <unixmania@gmail.com>

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Thomas Petazzoni]

Hello Carlos,

On Mon, 13 Apr 2020 20:41:11 -0300
Carlos Santos <unixmania@gmail.com> wrote:

> > There's been feedback from both Yann and me on this patch, and both of
> > us think this is not the approach we want to take. Instead, we'd rather
> > see everything installed to STAGING_DIR as the way of fixing the
> > original issue.
> >
> > So I've marked both patches as Rejected in patchwork. Of course, if
> > other people disagree with this decision, we can always revisit and
> > rediscuss the matter.  
> 
> Just to remind you, the problem was reported two and a half years ago
> and the situation is still the same. Perfect is the enemy of good and
> later easily becomes never. Anyway, your project, your rules.

Why do you have to be so aggressive immediately ? Don't you have in
your palette of expression, some intermediate feelings, where you can
express concern and possibly frustration, without the agression ? Be
constructive instead of aggressive ?

It is deeply annoying that we can never say anything about your patches
and the approach you're taking without getting back a missile. This is
not how open-source works. We discuss, understand each others concerns,
find good trade-offs and make progress.

Have you read our concerns ? As far as I can see, your only reply was
to make it optional, which really only makes the whole thing even more
complicated.

I would really like to build a more constructive and collaborative work
relationship with you. You are always sending very good and valuable
contributions of high-quality, but there's a total impossibility of
discussing them if we have some fundamental concerns about them. All of
us maintainers always fear to reply negatively to one of your
contributions, because we know we are going to get back an aggression.
This is not how it should work. This is not why we all want to
contribute together to the same project.

Best regards,

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

[Buildroot] [PATCH v2 1/2] Strip binaries in the rootfs creation instead of in target-finalize

[Carlos Santos]

ing Tue, Apr 14, 2020 at 2:36 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Carlos,
>
> On Mon, 13 Apr 2020 20:41:11 -0300
> Carlos Santos <unixmania@gmail.com> wrote:
>
> > > There's been feedback from both Yann and me on this patch, and both of
> > > us think this is not the approach we want to take. Instead, we'd rather
> > > see everything installed to STAGING_DIR as the way of fixing the
> > > original issue.
> > >
> > > So I've marked both patches as Rejected in patchwork. Of course, if
> > > other people disagree with this decision, we can always revisit and
> > > rediscuss the matter.
> >
> > Just to remind you, the problem was reported two and a half years ago
> > and the situation is still the same. Perfect is the enemy of good and
> > later easily becomes never. Anyway, your project, your rules.

---8<---
> Have you read our concerns ? As far as I can see, your only reply was
> to make it optional, which really only makes the whole thing even more
> complicated.
---8<---

I have read the concerns. They sound reasonable but at the same time
there was an assumption (or promise) that the problem would vanish
once the dichotomy between staging/ and target/ be eliminated. Fair
enough, but no ETA was provided and the fact that the problem still
exists should be an alert about how difficult the solution is.

So two questions must be answered:

1. Is the problem reported by Ciro Santilli in bug 10386 real? If the
answer is "no", there's nothing else to argue about. Otherwise, jump
to question 2.

2. Is anybody able to estimate how long it will take to provide a solution?

-- 
Carlos Santos <unixmania@gmail.com>

[Buildroot] [PATCH v2 2/2] toolchain: install gdbinit under TARGET_DIR

[unixmania at gmail.com]

From: Carlos Santos <unixmania@gmail.com>

Now that binaries are stripped only in the root filesystem we can use
TARGET_DIR as sysroot in gdb, instead of STAGING dir. Install gdbinit
at target/usr/share/buildroot but exclude it from the root filesystem
since it's required only at the host side.

Update the documentation accordingly.

Signed-off-by: Carlos Santos <unixmania@gmail.com>
---
CC: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
CC: Ciro Santilli <ciro.santilli@gmail.com>
---
 docs/manual/quickstart.txt                            |  5 +++--
 docs/manual/using-buildroot-debugger.txt              | 11 +++++++----
 fs/common.mk                                          |  1 +
 toolchain/helpers.mk                                  |  4 ++--
 .../toolchain-external/pkg-toolchain-external.mk      |  4 ++--
 5 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/docs/manual/quickstart.txt b/docs/manual/quickstart.txt
index 74158ae249..d2e48b4540 100644
--- a/docs/manual/quickstart.txt
+++ b/docs/manual/quickstart.txt
@@ -108,8 +108,9 @@ This directory contains several subdirectories:
   use the tarball image generated in +images/+ and extract it as
   root. Compared to +staging/+, +target/+ contains only the files and
   libraries needed to run the selected target applications: the
-  development files (headers, etc.) are not present, the binaries are
-  stripped.
+  development files (headers, etc.) are not present. The binaries are stripped
+  in the generation of the root filesystem but are left unstripped in
+  +target/+.
 
 * +host/+ contains the installation of tools compiled for the host
   that are needed for the proper execution of Buildroot, including the
diff --git a/docs/manual/using-buildroot-debugger.txt b/docs/manual/using-buildroot-debugger.txt
index d5293beb53..599f9f77d1 100644
--- a/docs/manual/using-buildroot-debugger.txt
+++ b/docs/manual/using-buildroot-debugger.txt
@@ -35,15 +35,18 @@ Then, on the host, you should start the cross gdb using the following
 command line:
 
 ----------------------------
-<buildroot>/output/host/bin/<tuple>-gdb -x <buildroot>/output/staging/usr/share/buildroot/gdbinit foo
+<buildroot>/output/host/bin/<tuple>-gdb -x <buildroot>/output/target/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).
+directory where +foo+ is built or from from +output/target/+, as in
 
-The +<buildroot>/output/staging/usr/share/buildroot/gdbinit+ file will tell the
+----------------------------
+<buildroot>/output/host/bin/<tuple>-gdb -x <buildroot>/output/target/usr/share/buildroot/gdbinit output/target/usr/bib/foo
+----------------------------
+
+The +<buildroot>/output/target/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:
diff --git a/fs/common.mk b/fs/common.mk
index caa7825cbb..612baffca2 100644
--- a/fs/common.mk
+++ b/fs/common.mk
@@ -186,6 +186,7 @@ $$(BINARIES_DIR)/$$(ROOTFS_$(2)_FINAL_IMAGE_NAME): $$(ROOTFS_$(2)_DEPENDENCIES)
 	mkdir -p $$(ROOTFS_$(2)_DIR)
 	rsync -auH \
 		--exclude=/$$(notdir $$(TARGET_DIR_WARNING_FILE)) \
+		--exclude=/usr/share/buildroot \
 		$$(BASE_TARGET_DIR)/ \
 		$$(TARGET_DIR)
 
diff --git a/toolchain/helpers.mk b/toolchain/helpers.mk
index 6a4f7223c8..4ee3ba3e99 100644
--- a/toolchain/helpers.mk
+++ b/toolchain/helpers.mk
@@ -458,8 +458,8 @@ check_toolchain_ssp = \
 # 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
+	mkdir -p $(TARGET_DIR)/usr/share/buildroot/ ; \
+	echo "set sysroot $(TARGET_DIR)" > $(TARGET_DIR)/usr/share/buildroot/gdbinit
 
 # Given a path, determine the relative prefix (../) needed to return to the
 # root level. Note that the last component is treated as a file component; use a
diff --git a/toolchain/toolchain-external/pkg-toolchain-external.mk b/toolchain/toolchain-external/pkg-toolchain-external.mk
index c00211d59c..613e170855 100644
--- a/toolchain/toolchain-external/pkg-toolchain-external.mk
+++ b/toolchain/toolchain-external/pkg-toolchain-external.mk
@@ -469,7 +469,7 @@ endef
 #
 # Generate gdbinit file for use with Buildroot
 #
-define TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT
+define TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBINIT
 	$(Q)if test -f $(TARGET_CROSS)gdb ; then \
 		$(call MESSAGE,"Installing gdbinit"); \
 		$(gen_gdbinit_file); \
@@ -569,7 +569,6 @@ define $(2)_INSTALL_STAGING_CMDS
 	$$(TOOLCHAIN_EXTERNAL_CREATE_STAGING_LIB_SYMLINK)
 	$$(TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS)
 	$$(TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER)
-	$$(TOOLCHAIN_EXTERNAL_INSTALL_GDBINIT)
 endef
 
 # Even though we're installing things in both the staging, the host
@@ -579,6 +578,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_GDBINIT)
 	$$(TOOLCHAIN_EXTERNAL_FIXUP_UCLIBCNG_LDSO)
 endef
 
-- 
2.18.1