[SOLVED] Generating GDB core dumps after attaching

[catnarok]

Solution: the -no-pie CFLAG. The kernel is hardened on this machine (whoops).

This is an issue I can't reproduce on Debian but is present in the latest stable and unstable versions of sys-devel/gdb (7.12.1 and 8.0.1 respectively). You can use the 'generate-core-file' (or 'gcore') command inside GDB to save your debugging state to a file. On Gentoo this works when you use GDB to launch the process, but if you attach to one after it has already started, the resulting dump isn't the same as it would have been when starting through GDB, and it's not helpful. This affects attaching via command line (`gdb </binary/path> <PID>` or `gdb -p <PID>`) or inside GDB (`attach <PID>`).

For example, while debugging a running process you later attached to, you can run a backtrace and the output will be correct. However, if you then create a core file, kill GDB and its inferior process, then relaunch GDB using this core file, the backtrace output will be gibberish. A core dump generated from a process you started within GDB will be correct.

Could it be my 'hardened/linux/x86' profile, or my kernel config?

I have a special package.env setup for sys-libs/glibc so that dev-util/valgrind will run (but I doubt it matters):

Code: Select all

CFLAGS="${CFLAGS} -ggdb"
CXXFLAGS="${CXXFLAGS} -ggdb"
FEATURES="${FEATURES} splitdebug"
USE="debug"

Here's a working backtrace:

Code: Select all

(gdb) bt
#0  0xb7721b45 in __kernel_vsyscall ()
#1  0xb700452d in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:84
#2  0x00535ee0 in game_loop (s=5) at comm.cpp:394
#3  0x00535768 in run_the_game (port=4500) at comm.cpp:228
#4  0x005353dd in main (argc=2, argv=0xbfe44e64) at comm.cpp:155

And here's an example of a coredump backtrace after attaching:

Code: Select all

(gdb) bt
#0  0xb7721b45 in __kernel_vsyscall ()
#1  0xb700452d in ?? ()
#2  0x00888ba8 in ?? ()
#3  0x00535768 in get_profession_choice(int, int)::prof ()
#4  0x00000005 in ?? ()
#5  0x007cc732 in ?? ()
#6  0xbfe44b38 in ?? ()
#7  0x005353dd in get_profession_choice(int, int)::prof ()
#8  0x00001194 in ?? ()
#9  0xb6f26488 in ?? ()

Ideally this should read the same as the previous backtrace, but something has gone wrong. As I said earlier, this works fine on a Debian machine following the same procedure.