CODEWITHSUNDEEP
debugginggdbembedded-linuxbuildrootgdbserver
kzsnyk
kzsnyk

Reputation: 2211

Why is gdbserver not found when using the Linaro external toolchain in Buildroot?

I am using Buildroot 2018.02 for an IMX6 board and the Linaro external toochain 2017.11 based on GCC 2017.11 (GCC 7.2.1)

Now i am adding some debug tools such as gdbserver on the target.

Everything is OK if i use the option "Build cross gdb for the host" and selecting the gdb debugger version 7.11.x for the host along with the gdbserver (BR2_PACKAGE_GDB_SERVER) in the "Target Packages > Debugging,.." menu. There are also other version of gdb available in Buildroot such as 7.12.x and 8.0.x.

However, for an external toolchain the recommended way is : https://github.com/mbats/eclipse-buildroot-bundle/wiki/Tutorial-:-How-to-debug-a-remote-application-%3F which means to activate only the "Copy gdb server to the Target" option in Buildroot (although the post is a bit old)

I have noticed that the BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM description says that Linaro gdb is based on gdb 8.0 so a newer version that the one i am using (7.11.x).

But when i do that, i have the following message on the target board :

# gdbserver
-sh: gdbserver: not found

despite the following : 

# which gdbserver
/usr/bin/gdbserver

gdbserver binary is on the target.

How to fix this in Buildroot ?

Moreover i have two additional questions :

  1. Does it really matter to have the Linaro toolchain gdb instead of the gdb 7.11.x that works "out of the box" in my case ?
  2. If i don't use the Linaro gdb then should i use the gdb version 8.0.x ( because the Linaro version is based on the 8.0 of GDB ) ?

Thank you for your help.

Upvotes: 1

Views: 4002

Answers (2)

Arnout
Arnout

Reputation: 3464

The gdbserver binary in the Linaro 2017.11 toolchain is broken: it requests /usr/lib/ld.so.1 as the program interpreter (see below), but that program interpreter doesn't exist.

You can try to create a symlink /usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 (add that to your filesystem overlay if it works). Alternatively, you can specify the program interpreter explicitly by putting it before the executable, i.e. /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver.

The "program interpreter" is a parameter of an ELF file that points to a program that is used to load the ELF file into memory and to start executing it. The main responsibility of the program interpreter is to find and load the dynamic libraries that the program needs. Thus, it is usually called the "dynamic library loader", or ld.so. It is built and installed together with the toolchain - specifically, the standard C library (glibc). When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). Apparently Linaro did something really peculiar to end up with a wrong program interpreter in the gdbserver executable.

Upvotes: 3

Employed Russian
Employed Russian

Reputation: 213526

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

  1. The gdbserver is a dynamically linked binary, and
  2. The ELF interpreter that this binary is linked to use is not present on the target system.

Use readelf -l /usr/bin/gdbserver | grep -i interpreter to find out what runtime loader this gdbserver requires. Verify that that file is not present on the target. Copy it to the target and enjoy.

Upvotes: 2

Related Questions