Good day,
I'm developing on the Allwinner A20 & A33 CPUs, which contains ARM cores.
I've first noticed the segfault during remote debugging, using gdbserver,
from my host PC to the target. Debugging the the application directly on
the target did not cause this problem. Performing the remote debugging from
a 32-bit host to the 32-bit target made no difference. That seemed to
eliminate the possibility of a 64/32 bit compatibility issue.
My setup:
Host PC:
Kubuntu 16.04 64-bit
Toolchain: gcc-linaro-6.1.1-2016.08
: gdb version (Linaro_GDB-2016.08) 7.11.1.20160801-git
Obtained from: https://releases.linaro.org/components/toolchain/binaries
Target:
Ubuntu 16.04 ARMHF
: GDB version: (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Illustrating the problem
------------------------------
Program: main.c
#include <stdio.h>
int main (void)
{
printf("Hallo world!\n");
return 0;
}
Compile on host PC:
$ arm-linux-gnueabihf-gcc -g main.c -o main_32
File signature:
$ file main_32
main_32: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked,
interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
BuildID[sha1]=cc1a4a1ff17da63f9f8362c84dffe54ee7fff4ff, not stripped
Remote target:
The executable (main_32) needs to be copied to the remote target
$ gdbserver :5555 main_32
Process main_32 created; pid = 904
Listening on port 5555
Remote debugging from host 192.168.7.2
Host PC:
$ arm-linux-gnueabihf-gdb ./main_32
(gdb) target remote 192.168.7.1:5555
Remote debugging using 192.168.7.1:5555
Reading /lib/ld-linux-armhf.so.3 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-linux-armhf.so.3 from remote target...
Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.23.so from remote target...
Reading /lib/.debug/ld-2.23.so from remote target...
(no debugging symbols found)...done.
0xb6fd7a40 in ?? () from target:/lib/ld-linux-armhf.so.3
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb6fd9822 in ?? () from target:/lib/ld-linux-armhf.so.3
To try and figure out where the segfault occurred I figured that the debug symbols needed to be loaded.
The gdb command 'set debug-file-directory' can be used to accomplish this. It seems that this command
is only relative to the host PC filesystem and not according to the remote target file system.
With 'set sysroot' the debugger can also be instructed to load all data locally instead of transferring it
runtime over the network.
I've copied the full contents of the SD card residing on the Allwinner A20 rootfs to a local directory on
the host PC: /opt/gnueabihf_rootfs
Illustrating the solution
-------------------------------
Required packages: apt-get install libc6-dbg
Remote target:
$ gdbserver :5555 main_32
Process main_32 created; pid = 912
Listening on port 5555
Remote debugging from host 192.168.7.2
Hallo world!
Child exited with status 0
Host PC:
$ arm-linux-gnueabihf-gdb ./main_32
(gdb) set debug-file-directory /opt/gnueabihf_rootfs/usr/lib/debug
(gdb) set sysroot /opt/gnueabihf_rootfs
(gdb) target remote 192.168.7.1:5555
Remote debugging using 192.168.7.1:5555
Reading symbols from /opt/gnueabihf_rootfs/lib/ld-linux-armhf.so.3...done.
Reading symbols from /opt/gnueabihf_rootfs/usr/lib/debug/lib/arm-linux-gnueabihf/ld-2.23.so...done.
0xb6fd7a40 in _start ()
(gdb) continue
Continuing.
Cannot parse expression `.L966 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Even though there is a warning regarding "Probes-based dynamic linker interface failed", the program
keeps on running correctly. The thread describing the GDB patch about the linker interface can be
read at: https://sourceware.org/ml/gdb-patches/2015-08/msg00629.html
It appears the work around was introduced around August 2015, but if you do not specify the path to
the debug symbols, the debugger still segfaults.
The 'set debug-file-directory' and 'set sysroot' can be added to the .gdbinit file to be applied
automatically when you start a remote debug session.
Regards,
Frikkie Thirion
