How can I set the path of a file-backed mapping for a core dump in GDB?

Question

I'm cross compiling on an x86 Ubuntu machine for an embedded ARM target.

If the application segfaults, I get a core dump.

When I run: gdb-multiarch my_app core

I get:

Reading symbols from my_app ...
warning: Can't open file /home/my_user/bin/my_app during file-backed mapping note processing
warning: Can't open file /usr/lib/aarch64-linux-gnu/libc.so.6 during file-backed mapping note processing
warning: Can't open file /usr/lib/aarch64-linux-gnu/libgcc_s.so.1 during file-backed mapping note processing
...
(gdb) bt
#0  0x0000aaaacab2cd50 in ?? ()
warning: (Internal error: pc 0x37 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x37 in read in psymtab, but not in symtab.)
#1  0x0000000000000038 in ?? (warning: (Internal error: pc 0x37 in read in psymtab, but not in symtab.)
)
warning: (Internal error: pc 0x37 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x37 in read in psymtab, but not in symtab.)
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

But if I move the arm binary to /home/my_user/bin/my_app on my host machine (which is the path the binary ran on the target) the backtrace works as expected and I can debug fine. While this works, it's a bit of a pain to replicate arbitrary paths on the host machine.

gdb support source, sysroot, and dynamic lib path mappings: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html and

set sysroot $PATH
set solib-search-path $PATH

But it's unclear if any of these are relevant for file-backed mapping.

I'm also not entirely clear why the core dump is referencing the file-backed mapping instead of using the symbols that are loaded from the binary I specify as the gdb argument.

Any idea of how to avoid making the arbitrary paths? It seems like there might be a way with chroot, but that seems like that would have its own issues.

Answer 1

OK, I figured this out with a little more trial and error.

It seems like these "file-backed mapping" paths are relative to sysroot. This means that I could duplicate the path in a temporary directory, set the sysroot, and have things load correctly.

For example if my working directory is /tmp. Running

mkdir -p ./home/my_user/bin/
mv my_app ./home/my_user/bin/
gdb-multiarch ./home/my_user/bin/my_app core

works.

It also worked to set the sysroot with: gdb-multiarch /tmp/home/my_user/bin/my_app core --init-eval-command="set sysroot /tmp/"