Comment 6 for bug 1576432

Frikkie Thirion (frixbuntu) wrote :

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)
            Obtained from:
  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/, 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

Host PC:
$ arm-linux-gnueabihf-gdb ./main_32
  (gdb) target remote
  Remote debugging using
  Reading /lib/ from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files
           locally instead.
  Reading /lib/ from remote target...
  Reading symbols from target:/lib/ /lib/ from remote
  Reading /lib/.debug/ from remote target...
  (no debugging symbols found)...done.
  0xb6fd7a40 in ?? () from target:/lib/

(gdb) continue
  Program received signal SIGSEGV, Segmentation fault.
  0xb6fd9822 in ?? () from target:/lib/

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

  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

  Remote debugging using
  Reading symbols from /opt/gnueabihf_rootfs/lib/
  Reading symbols from /opt/gnueabihf_rootfs/usr/lib/debug/lib/arm-linux-gnueabihf/ld-
  0xb6fd7a40 in _start ()

  (gdb) continue
  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:

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.

Frikkie Thirion