Version: valgrind-3.5.0-9.x86_64 (using Devel) OS: Linux Installed from: Compiled sources valgrind --db-attach pie-executable does not currently work if /lib64/ld*.so is not prelinked. FSF GDB support for PIE (Position Independent Executable; built using -fPIE -pie) debugging has been checked-in to CVS HEAD (->gdb-7.1): http://sourceware.org/ml/gdb-patches/2010-01/msg00233.html It currently works for all these cases (simplified): gdb -p normal-executable gdb -p pie-executable-prelinked gdb -p pie-executable-unprelinked valgrind --db-attach normal-executable valgrind --db-attach pie-executable-prelinked-only-if-ld.so-is-prelinked valgrind --db-attach pie-executable-unprelinked-only-if-ld.so-is-prelinked It does not work for: valgrind --db-attach pie-executable-prelinked-only-if-ld.so-is-unprelinked valgrind --db-attach pie-executable-unprelinked-only-if-ld.so-is-unprelinked GDB generally wants to know AUXV of the debugged process. With AUXV and its AT_ENTRY value it can find the executable offset and relocate its symbols for it. Normally /proc/PID/auxv is read to find the AUXV content. But with valgrind it does not match, therefore for attachments it rather uses "_dl_auxv" (located in ld.so). GDB cannot use backtrace from main to _start to find the valgrind-modified auxv there as the initial thread may have exited (+it would be too fragile anyway). But to locate "_dl_auxv" we need relocated symbols for ld.so which is a chicked-and-egg problem. DT_DEBUG is in the main executable (which would point us at ld.so load address) but we need AUXV to find out how to relocate symbols for the PIE main executable. Therefore we known neither the main executable offset (as it is PIE) and therefore neither DT_DEBUG and therefore neither ld.so offset (as it is PIC and not prelinked loaded at arbitrary address) and therefore neither "_dl_auxv" offset and /proc/PID/auxv is invalid with valgrind attachments. There is everything floating. Therefore suggesting to create besides %f and %p --db-command substitutions also some %a producing string "0x7fffffffd7e0" which would correspond to "the_iifii.client_auxv" (or where is the AUXV address stored). GDB will get corresponding "--auxv" commandline option / CLI setting. Thanks.
Since Valgrind 3.7.0, there is an embedded gdbserver, which returns the auxv to GDB. Is that working in your case ?
Yes, it works, thanks: 0x00000030005087a9 in main () at pie.c:4 4 *(int *)0=0; BTW it would be nice to start GDB automatically, like with --db-attach=yes. gdb ./pie -ex 'target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=11325'
(In reply to comment #2) > Yes, it works, thanks: > 0x00000030005087a9 in main () at pie.c:4 > 4 *(int *)0=0; > > BTW it would be nice to start GDB automatically, like with --db-attach=yes. > gdb ./pie -ex 'target remote | /usr/lib64/valgrind/../../bin/vgdb > --pid=11325' We could implement --db-attach=vgdb to indicate that the gdbserver should be used to "attach" (rather than the old --db-attach technique of forking the process, and have the parent launching a gdb to attach to the forked process). However, if the Valgrind process launches a gdb as suggested above, I am wondering what will happen with stdin, C-c, ... when continue is done in the gdb.
We should just scrap the old db-attach technology I suspect...
With "set target-async on" it should work (resume->target_terminal_inferior->remote_terminal_inferior). With "set target-async off" (the current default) it will probably not. "set target-async on" should fortunately become the default in a reasonable time.