Reputation: 1173
I am running:
(architecture set to arm in .gdbinit) locally and
gdbserver` on the target.Cross compilation and remote deployment is successful. However, there appears to be some library issue when I run on the remote target. Output from gdb-multiarch
below (superfluous text removed):
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11 Copyright (C) 2016 Free Software
Foundation, Inc. License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html This GDB was configured as
"x86_64-linux-gnu".
Program stopped. 0x76fd7a40 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Execution stops at main
. However, it doesn't appear to stop due to a breakpoint. The stop appears to be the result of some library issue possibly and unresolved symbol (or something more serious) resulting in the ??
.
I have set sysroot
in the .gdbinit
file to indicate where the shared libraries can be found. The StepIn, StepOut icons are hi-lighted in Eclipse, and I can read ARM registers if I press pause and see which core is being used to run the process (with process ID)!
After further resume & pause operations a segmentation fault occurs:
Program stopped. 0x76fe2e92 in ?? () from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.so
Program received signal SIGSEGV, Segmentation fault. 0x76fd905e in ??
() from
/home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf/ld-2.23.soProgram terminated with signal SIGSEGV, Segmentation fault. The
program no longer exists.
Any ideas? (I am very much new to Linux as it probably shows.)
Thanks for the questions which have resulted in further exploration below:
In Eclipse I started GDB by selecting Debug Configuration
and then choosing the remote configuration that I had set up.
The code is very simple, consisting of a stream operator to output some text and then a loop, however it is never reached. I think I have just managed to reproduce the issue from the command line. Incidentally I started the target going first. (Again superfluous text was removed for clarity.)
gdb-multiarch Hello_Raspberry_Pi
Reading symbols from Hello_Raspberry_Pi...done.
The target architecture is assumed to be arm
(gdb) target remote ubuntumate-pi
(gdb) target remote 192.168.0.12:2345
Remote debugging using 192.168.0.12:2345
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
(gdb) set architecture arm
The target architecture is assumed to be arm
(gdb) set sysroot /home/fred/raspberrypi/rootfs/lib/arm-linux-gnueabihf
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
(gdb)
The target side behaved as would be expected:
fred@UbuntuMATE-Pi:~/Hello_Raspberry_Pi$ gdbserver 192.168.0.7:2345 Hello_Raspberry_Pi
Process Hello_Raspberry_Pi created; pid = 17363
Listening on port 2345
Remote debugging from host 192.168.0.7
So perhaps Unable to find dynamic linker breakpoint function.
is a big clue?
It would appear that I had defined Shared Libraries
incorrectly. When I deleted this setting something closer to expected behaviour occurred. As shown below, however I there is still a warning that I would like to remove:
For help, type "help".
Type "apropos word" to search for commands related to "word".
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initialisers
and track explicitly loaded dynamic code.
0x76fd7a40 in ?? ()
Breakpoint 2, main () at ../src/Hello_Raspberry_Pi.cpp:18
18 cout << "I'm in the While loop and the value of variable i is: " << i << endl;
Breakpoint 1, main () at ../src/Hello_Raspberry_Pi.cpp:20
20 usleep(1000000); //wait for 1 seconds
So now Eclipse does breakpoint at main and permit stepping - finally!
Upvotes: 3
Views: 2025
Reputation: 41
I also faced problems similar to this, getting segmentation fault from ld.so. Did the following steps to fix it.
Upvotes: 2