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 :

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 ?

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.

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

It could be a broken symlink, or gdbserver is a shellscript with an invalid shebang line. ls- l /usr/bin/gdbserver or file /usr/bin/gdbserver will probably help to debug this. Apart from that, does your external toolchain contain a gdbserver binary?

– arved
Jan 2 at 12:16

ls -l output is -rwxr-xr-x 1 root root 822000 Dec 31 2018 /usr/bin/gdbserver . This is not a shell script or broken link. The package used by Buildroot is gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz and can be found here releases.linaro.org/components/toolchain/binaries/7.2-2017.11/… . It contains a gdbserver binary and a cross-gdb.

– Scab
Jan 2 at 13:43

Does typing /usr/bin/gdbserver result in an error message?

– Mark Plotnick
Jan 2 at 15:46

Yes it's the same error message

– Scab
Jan 2 at 15:47

1

Try file /usr/bin/gdbserver or try ldd on it or work out the options for readelf - that error message can confusingly be triggered by finding a file that is ruled unexectuable, for example it is in the wrong format, claims to be for the wrong ABI or relies on a different dynamic linker.

– Chris Stratton
Jan 2 at 21:13

add a comment |

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.

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 :

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 ?

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.

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

It could be a broken symlink, or gdbserver is a shellscript with an invalid shebang line. ls- l /usr/bin/gdbserver or file /usr/bin/gdbserver will probably help to debug this. Apart from that, does your external toolchain contain a gdbserver binary?

– arved
Jan 2 at 12:16

ls -l output is -rwxr-xr-x 1 root root 822000 Dec 31 2018 /usr/bin/gdbserver . This is not a shell script or broken link. The package used by Buildroot is gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz and can be found here releases.linaro.org/components/toolchain/binaries/7.2-2017.11/… . It contains a gdbserver binary and a cross-gdb.

– Scab
Jan 2 at 13:43

Does typing /usr/bin/gdbserver result in an error message?

– Mark Plotnick
Jan 2 at 15:46

Yes it's the same error message

– Scab
Jan 2 at 15:47

1

Try file /usr/bin/gdbserver or try ldd on it or work out the options for readelf - that error message can confusingly be triggered by finding a file that is ruled unexectuable, for example it is in the wrong format, claims to be for the wrong ABI or relies on a different dynamic linker.

– Chris Stratton
Jan 2 at 21:13

add a comment |

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.

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 :

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 ?

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.

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

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.

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 :

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 ?

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.

debugging gdb embedded-linux buildroot gdbserver

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

edited Jan 3 at 8:17

asked Jan 2 at 10:19

Scab

706820

asked Jan 2 at 10:19

Scab

706820

asked Jan 2 at 10:19

Scab

706820

It could be a broken symlink, or gdbserver is a shellscript with an invalid shebang line. ls- l /usr/bin/gdbserver or file /usr/bin/gdbserver will probably help to debug this. Apart from that, does your external toolchain contain a gdbserver binary?

– arved
Jan 2 at 12:16

ls -l output is -rwxr-xr-x 1 root root 822000 Dec 31 2018 /usr/bin/gdbserver . This is not a shell script or broken link. The package used by Buildroot is gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz and can be found here releases.linaro.org/components/toolchain/binaries/7.2-2017.11/… . It contains a gdbserver binary and a cross-gdb.

– Scab
Jan 2 at 13:43

Does typing /usr/bin/gdbserver result in an error message?

– Mark Plotnick
Jan 2 at 15:46

Yes it's the same error message

– Scab
Jan 2 at 15:47

1

Try file /usr/bin/gdbserver or try ldd on it or work out the options for readelf - that error message can confusingly be triggered by finding a file that is ruled unexectuable, for example it is in the wrong format, claims to be for the wrong ABI or relies on a different dynamic linker.

– Chris Stratton
Jan 2 at 21:13

add a comment |

It could be a broken symlink, or gdbserver is a shellscript with an invalid shebang line. ls- l /usr/bin/gdbserver or file /usr/bin/gdbserver will probably help to debug this. Apart from that, does your external toolchain contain a gdbserver binary?

– arved
Jan 2 at 12:16

ls -l output is -rwxr-xr-x 1 root root 822000 Dec 31 2018 /usr/bin/gdbserver . This is not a shell script or broken link. The package used by Buildroot is gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz and can be found here releases.linaro.org/components/toolchain/binaries/7.2-2017.11/… . It contains a gdbserver binary and a cross-gdb.

– Scab
Jan 2 at 13:43

Does typing /usr/bin/gdbserver result in an error message?

– Mark Plotnick
Jan 2 at 15:46

Yes it's the same error message

– Scab
Jan 2 at 15:47

1

Try file /usr/bin/gdbserver or try ldd on it or work out the options for readelf - that error message can confusingly be triggered by finding a file that is ruled unexectuable, for example it is in the wrong format, claims to be for the wrong ABI or relies on a different dynamic linker.

– Chris Stratton
Jan 2 at 21:13

It could be a broken symlink, or gdbserver is a shellscript with an invalid shebang line. ls- l /usr/bin/gdbserver or file /usr/bin/gdbserver will probably help to debug this. Apart from that, does your external toolchain contain a gdbserver binary?

– arved
Jan 2 at 12:16

ls -l output is -rwxr-xr-x 1 root root 822000 Dec 31 2018 /usr/bin/gdbserver . This is not a shell script or broken link. The package used by Buildroot is gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz and can be found here releases.linaro.org/components/toolchain/binaries/7.2-2017.11/… . It contains a gdbserver binary and a cross-gdb.

– Scab
Jan 2 at 13:43

Does typing /usr/bin/gdbserver result in an error message?

– Mark Plotnick
Jan 2 at 15:46

Yes it's the same error message

– Scab
Jan 2 at 15:47

Try file /usr/bin/gdbserver or try ldd on it or work out the options for readelf - that error message can confusingly be triggered by finding a file that is ruled unexectuable, for example it is in the wrong format, claims to be for the wrong ABI or relies on a different dynamic linker.

– Chris Stratton
Jan 2 at 21:13

add a comment |

2 Answers
2

active

oldest

votes

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.

answered Jan 3 at 13:47

Arnout

1,7191118

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

add a comment |

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

The gdbserver is a dynamically linked binary, and

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.

answered Jan 3 at 3:03

Employed Russian

127k20173239

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54004557%2fwhy-is-gdbserver-not-found-when-using-the-linaro-external-toolchain-in-buildroot%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

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.

answered Jan 3 at 13:47

Arnout

1,7191118

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

add a comment |

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.

answered Jan 3 at 13:47

Arnout

1,7191118

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

add a comment |

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.

answered Jan 3 at 13:47

Arnout

1,7191118

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.

answered Jan 3 at 13:47

Arnout

1,7191118

answered Jan 3 at 13:47

Arnout

1,7191118

answered Jan 3 at 13:47

Arnout

1,7191118

answered Jan 3 at 13:47

Arnout

1,7191118

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

add a comment |

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

/usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 or /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver ends up in a segfault but i guess you are right : the Linaro gdbserver is broken so i am afraid there is nothing i can do to fix this in Buildroot. But does it really matter if i use gdb 7.11 or 8.0 instead - and not the Linaro one ?

– Scab
Jan 3 at 14:00

The statement "prefer to use the gdb/gdbserver that comes with the toolchain" is a kind of ancient lore. I don't know what was the reasoning behind that statement and if it is still valid. The gdb/gdbserver 7.11 or 8.0 built by Buildroot should work fine.

– Arnout
Jan 4 at 10:08

"When a program is linked, the linker will also set the program interpreter (it is copied from libc.so). " -- the parenthesized part is incorrect. Your answer would be better without it.

– Employed Russian
Jan 4 at 16:13

add a comment |

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

The gdbserver is a dynamically linked binary, and

The ELF interpreter that this binary is linked to use is not present on the target system.

answered Jan 3 at 3:03

Employed Russian

127k20173239

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

add a comment |

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

The gdbserver is a dynamically linked binary, and

The ELF interpreter that this binary is linked to use is not present on the target system.

answered Jan 3 at 3:03

Employed Russian

127k20173239

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

add a comment |

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

The gdbserver is a dynamically linked binary, and

The ELF interpreter that this binary is linked to use is not present on the target system.

answered Jan 3 at 3:03

Employed Russian

127k20173239

# gdbserver
-sh: gdbserver: not found

depsite the following :

# which gdbserver
/usr/bin/gdbserver

Most likely:

The gdbserver is a dynamically linked binary, and

The ELF interpreter that this binary is linked to use is not present on the target system.

answered Jan 3 at 3:03

Employed Russian

127k20173239

answered Jan 3 at 3:03

Employed Russian

127k20173239

answered Jan 3 at 3:03

Employed Russian

127k20173239

answered Jan 3 at 3:03

Employed Russian

127k20173239

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

add a comment |

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

Thanks for pointing that out. Indeed the file was not present.

– Scab
Jan 4 at 11:23

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu