Debugging a coredump generated by an ASLR enabled system

Question

I have a coredump extracted from a remote target in production. I need to debug it on my own computer since the target lacks gdb-server. Locally, I have the corresponding tooling, debug symbols and source code.

The problem is that when I load this core into gdb most, if not all, addresses and symbols are not resolved:

#15 0x00007ffc78fd87a0 in ?? ()
#16 0x0000000002147bb0 in ?? ()
#17 0x00007ffc78fd8740 in ?? ()
#18 0x0000000000000006 in ?? ()
#19 0x0000332d70667351 in ?? ()
#20 0x00000000021612a0 in ?? ()
#21 0x00007ffc78fd8760 in ?? ()
#22 0x0000000000000006 in ?? ()
#23 0x0000332d70667351 in ?? ()
#24 0x00000000021612a0 in ?? ()
#25 0x0000000000000012 in ?? ()
#26 0x00000000021468e0 in ?? ()

If I recompile some module of the application with -no-pie -fno-PIE, the frames for that exact module become available. However, that is not an option. The target is in production and needs this security feature enabled.

My main goal is to have some way of debugging this system post-mortem in another computer since the only thing I'll have from a crash is a coredump that I can extract. Is there any way around this? Am I missing something? Perhaps, some way of embedding the exact memory offsets that were used when the application was running to the coredump; in a way that gdb will read.

Answer 1

After two days and I've just figured it out. A rookie mistake.

I was calling gdb on the .debug version of the app instead of the app itself:

$ cd ~/sysroot
$ x86_64-linux-gdb usr/bin/.debug/app -c <path_to_dump>

instead of:

$ cd ~/sysroot
x86_64-linux-gdb usr/bin/app -c <path_to_dump>

I've been reusing that command from bash history for the past 2 days and it was giving me a false positive. I corrected it and all symbols show up.