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 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. Regards, Frikkie Thirion