From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Wed, 20 Mar 2013 21:54:47 +0100 Subject: [Buildroot] [PATCH] Fix external toolchain gdbserver copy path for using buildroot-generated toolchain In-Reply-To: References: Message-ID: <20130320215447.0d7c272f@skate> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Dear Worth, Kevin, On Wed, 20 Mar 2013 17:25:46 +0000, Worth, Kevin wrote: > I have a few different toolchains and boards, and I'm using buildroot to generate toolchains and system images for them. I'm building my toolchain using O=board1.toolchain, then my system using O=board1. I simply set my system defconfig to use an external toolchain, which points to the matching toolchain directory at $(TOPDIR)/board1.toolchain/host/usr. > > This works quite nicely so far (I can do a clean system build in about 10 minutes without the 20 minute toolchain build), except that the gdbserver generated by buildroot goes to output/target/usr/bin/gdbserver (appropriately so, since it runs on the target, not the host). > > However, toolchain/toolchain-external/ext-tool.mk only looks in sysroot and sysroot/../debug-root; neither of which is the right spot for buildroot's generated toolchain, and it dies as follows: > > >>> Checking external toolchain settings > >>> Copying external toolchain libraries to target... > >>> Copying external toolchain sysroot to staging... > >>> Copying gdbserver > Could not find gdbserver in external toolchain > make: *** [/.../stamps/ext-toolchain-installed] > > This patch is a simple fix to add buildroot's generated gdbserver path list of searched directories. Perhaps I should be configuring my system to point somewhere besides board1.toolchain/host/usr, but I've been unable to find anything around the web. Another alternative could be to create a debug-root symlink (a path already searched by ext-tool.mk) in the buildroot toolchain generation of gdb that points to the host directory, but I'm not sure if that is the intended purpose of the debug-root path. > > Looking at toolchain/gdb/gdb.mk, there is a conditional check for a (possibly stale, I can't find it elsewhere) configuration option- BR2_CROSS_TOOLCHAIN_TARGET_UTILS: > > $(TARGET_DIR)/usr/bin/gdbserver: $(GDB_SERVER_DIR)/gdbserver > ifeq ($(BR2_CROSS_TOOLCHAIN_TARGET_UTILS),y) > mkdir -p $(STAGING_DIR)/usr/$(GNU_TARGET_NAME)/target_utils > install -c $(GDB_SERVER_DIR)/gdbserver \ > $(STAGING_DIR)/usr/$(GNU_TARGET_NAME)/target_utils/gdbserver > endif > install -c -D $(GDB_SERVER_DIR)/gdbserver $(TARGET_DIR)/usr/bin/gdbserver > > Perhaps this would be a candidate for putting gdbserver in a place that ext-tool.mk will know to pick it up? Aaah, correct, this code is dead. I'm currently reworking the gdb integration (to turn it into a real package), so I'll try to address that at the same time. I think the right fix is to get the gdbserver installed in $(STAGING_DIR)/usr/bin/, from where it can be picked up by the ext-tool.mk logic. > - for d in $${ARCH_SYSROOT_DIR} $${ARCH_SYSROOT_DIR}/../debug-root/ ; do \ > + for d in $${ARCH_SYSROOT_DIR} $${ARCH_SYSROOT_DIR}/../debug-root/ $${ARCH_SYSROOT_DIR}/../../../../target/; do \ We don't want to look in target/, because the normal way to generate a toolchain with Buildroot is to configure BR2_HOST_DIR to point to some place (say /opt/foobar) where the toolchain will be installed. And in that case, only the contents of the host/ directory is installed, so looking at target/ is not correct. Thanks a lot for your investigation anyway! I'll come up with a patch that fixes that. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com