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.
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 the debug symbols need 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.
Make sure the debug symbols are on the remote file system:
# apt-get install libc6-dbg
Copy 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
-------------------------
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.
Note: Activating the kernel option: CONFIG_OABI_COMPAT did not fix the problem on the Allwinner A20 or A33.
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: 6.1.1-2016. 08 GDB-2016. 08) 7.11.1.20160801-git
Obtained from: https:/ /releases. linaro. org/components/ toolchain/ binaries 0ubuntu1~ 16.04) 7.11.1
Host PC:
Kubuntu 16.04 64-bit
Toolchain: gcc-linaro-
: gdb version (Linaro_
Target:
Ubuntu 16.04 ARMHF
: GDB version: (Ubuntu 7.11.1-
Illustrating the problem ------- ------- --- gnueabihf- gcc -g main.c -o main_32
interpreter /lib/ld- linux-armhf. so.3, for GNU/Linux 2.6.32,
BuildID[ sha1]=cc1a4a1ff 17da63f9f8362c8 4dffe54ee7fff4f f, not stripped
-------
Program: main.c
#include <stdio.h>
int main (void)
{
printf("Hallo world!\n");
return 0;
}
Compile on host PC:
$ arm-linux-
File signature:
$ file main_32
main_32: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked,
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: gnueabihf- gdb ./main_32 linux-armhf. so.3 from remote target... linux-armhf. so.3 from remote target... /lib/ld- linux-armhf. so.3... Reading /lib/ld-2.23.so from remote ld-2.23. so from remote target... /lib/ld- linux-armhf. so.3
$ arm-linux-
(gdb) target remote 192.168.7.1:5555
Remote debugging using 192.168.7.1:5555
Reading /lib/ld-
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files
locally instead.
Reading /lib/ld-
Reading symbols from target:
target...
Reading /lib/.debug/
(no debugging symbols found)...done.
0xb6fd7a40 in ?? () from target:
(gdb) continue /lib/ld- linux-armhf. so.3
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb6fd9822 in ?? () from target:
To try and figure out where the segfault occurred the debug symbols need to be loaded. 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.
The gdb command 'set debug-file-
With 'set sysroot' the debugger can also be instructed to load all data locally instead of transferring it runtime over the network.
Make sure the debug symbols are on the remote file system: rootfs
# apt-get install libc6-dbg
Copy the full contents of the SD card residing on the Allwinner A20 rootfs to a local directory on
the host PC: /opt/gnueabihf_
Illustrating the solution ------- ------- ----
-------
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: gnueabihf- gdb ./main_32 directory /opt/gnueabihf_ rootfs/ usr/lib/ debug rootfs
$ arm-linux-
(gdb) set debug-file-
(gdb) set sysroot /opt/gnueabihf_
(gdb) target remote 192.168.7.1:5555
Remote debugging using 192.168.7.1:5555 rootfs/ lib/ld- linux-armhf. so.3... done. rootfs/ usr/lib/ debug/lib/ arm-linux- gnueabihf/ ld-
Reading symbols from /opt/gnueabihf_
Reading symbols from /opt/gnueabihf_
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.
Note: Activating the kernel option: CONFIG_OABI_COMPAT did not fix the problem on the Allwinner A20 or A33.
Regards,
Frikkie Thirion