Looking a little further, it looks like gdb does "just" not
know where the executable was mapped in memory, therefore it
gets mapped to 0x0 instead of 0x108000 in my example below.
Debugging such a "pie vgcore" file would be possible
if the debug symbols are loaded manually to the "right" address.
Kind regards,
Bernhard
$ valgrind --vgdb=yes --vgdb-error=0 ./test
$ gdb -q ./test
(gdb) target remote | vgdb
(gdb) cont
(gdb) info target
...
Local exec file:
`/home/benutzer/test', file type elf64-x86-64.
Entry point: 0x109040
0x00000000001082a8 - 0x00000000001082c4 is .interp
...
0x0000000000109040 - 0x00000000001091a1 is .text
...
0x0000000004874320 - 0x00000000049bd6b9 is .text in
/lib/x86_64-linux-gnu/libc.so.6
...
(gdb) cont
(gdb) cont
$ gdb ./test vgcore*
(gdb) bt
#0 0x000000000010912e in ?? ()
#1 0x0000000000109140 in ?? ()
#2 0x0000000004875d0a in ?? ()
...
(gdb) info target
Symbols from "/home/benutzer/test".
Local core dump file:
`/home/benutzer/vgcore.7308', file type elf64-x86-64.
0x0000000000108000 - 0x0000000000109000 is load1
...
Local exec file:
`/home/benutzer/test', file type elf64-x86-64.
Entry point: 0x1040
...
0x0000000000001040 - 0x00000000000011a1 is .text
...
(gdb) add-symbol-file ./test -s .text 0x0000000000109040
add symbol table from file "./test" at
.text_addr = 0x109040
(y or n) y
Reading symbols from ./test...
(gdb) add-symbol-file /lib/x86_64-linux-gnu/libc.so.6 -s .text
0x0000000004874320
add symbol table from file "/lib/x86_64-linux-gnu/libc.so.6" at
.text_addr = 0x4874320
(y or n) y
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from
/usr/lib/debug/.build-id/b7/2adf59ac0a673d1eeb261e662364507cfc8615.debug...
(gdb) bt
#0 main () at test.c:2
#1 0x0000000004875d0a in __libc_start_main (main=0x109125 <main>, argc=1, argv=0x1fff000538,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x1fff000528) at ../csu/libc-start.c:308
#2 0x000000000010906a in _start ()
(gdb) up
...
(gdb) down
#0 main () at test.c:2
2 *(int*)0 = 0;
