Fix external toolchain gdbserver copy path for using buildroot-generated toolchain

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?


Signed-off-by: Kevin Worth <kevin.worth_at_hp.com>
---
 toolchain/toolchain-external/ext-tool.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

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

Thanks- I figured I could at least offer some approach to fix it, even if it wasn't ideal. :)
This approach saves me a lot of time not having to rebuild toolchains, and is relatively easy to manage.

-Kevin Worth

Dear Worth, Kevin,

On Wed, 20 Mar 2013 22:27:08 +0000, Worth, Kevin wrote:

> Thanks- I figured I could at least offer some approach to fix it, even if it wasn't ideal. :)

Sure, your investigation was very nice, it clearly showed where the
problem was.

> This approach saves me a lot of time not having to rebuild toolchains, and is relatively easy to manage.

Of course.

I'll try to remember to Cc you when I come up with a patch that fixes
this.

Thanks!

Thomas