Hello,

I don't seem to be able to use vgcore files in gdb any more:
(gdb version 10.1-2)


$ cat test.c
int main(void) {
	*(int*)0 = 0;
}
$ gcc test.c -o test -g


$ valgrind ./test
[...]
$ gdb ./test vgcore*
[...]
Reading symbols from ./test...
[New LWP 1051166]
Core was generated by `'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000010912e in ?? ()
(gdb)


While without valgrind:


$ ./test
zsh: segmentation fault (core dumped)  ./test
$ gdb ./test core
[...]
Reading symbols from test...
[New LWP 1051373]]
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  main () at test.c:2
2		*(int*)0 = 0;
(gdb) p/x $pc
$2 = 0x55a04b9f812e
(gdb)

Samuel

Dear Maintainer,
I tried to find out when this started to happen.

And I found this issue in releases 11-bullseye, 10-buster and 9-stretch.
In 8-jessie such a vgcore shows in gdb the correct line information.

Further looking brought me to stretch/testing as of 29.10.2016,
where the issue starts to be visible.
At that date the gcc-6 version changed from 6.2.0-6 to 6.2.0-9.

The changelog [1] entries between these versions mention
a "--enable-default-pie".
So I tested to build the executable with the option "-no-pie"
in buster/stable which made the vgcore work. Therefore
this PIE option might be related.

Kind regards,
Bernhard

[1] https://metadata.ftp-master.debian.org/changelogs//main/g/gcc-6/gcc-6_6.3.0-18+deb9u1_changelog

Bernhard Übelacker, le sam. 11 sept. 2021 00:17:38 +0200, a ecrit:

Ooh, very probably indeed!

Samuel

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;

Dear Maintainer,
and some more digging with the help of rr-debugger led me to the
functions svr4_relocate_main_executable/exec_set_section_address
in gdb.

The latter gets not called in the valgrind core case,
because the vgcore file lacks an ".auxv" section,
which does exist inside a regular core:

     $ objdump -x core
     ...
     Sections:
     Idx Name          Size      VMA               LMA               File off  Algn
     ...
     5 .auxv         00000140  0000000000000000  0000000000000000  000007b8  2**3
                     CONTENTS

So I came up with attached patch for valgrind
that adds the ".auxv" section to the vgcore
and with such a vgcore gdb is able to show
the proper source line and shared library information.
(This patch still contains some informational debug printfs.)

Kind regards,
Bernhard


     gdb backtrace, where the ".auxv" sections is searched:

     868               section = bfd_get_section_by_name (core_bfd, ".auxv");
     (rr) bt
     #0  core_target::xfer_partial (this=0x563cec758120, object=TARGET_OBJECT_AUXV, annex=0x0, readbuf=0x563cec79d540 "\240Sa[J\177", writebuf=0x0, offset=0, len=4096, xfered_len=0x7fff66a72fc8) at /build/gdb-Nav6Es/gdb-10.1/gdb/corelow.c:868
     #1  0x0000563cebeee1be in target_xfer_partial (ops=0x563cec758120, object=TARGET_OBJECT_AUXV, annex=0x0, readbuf=0x563cec79d540 "\240Sa[J\177", writebuf=0x0, offset=0, len=<optimized out>, xfered_len=0x7fff66a72fc8) at /build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1160
     #2  0x0000563cebef0863 in target_read_partial (xfered_len=0x7fff66a72fc8, len=4096, offset=0, buf=<optimized out>, annex=0x0, object=TARGET_OBJECT_AUXV, ops=0x563cec758120) at /build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1387
     #3  target_read_alloc_1<unsigned char> (ops=ops@entry=0x563cec758120, object=object@entry=TARGET_OBJECT_AUXV, annex=annex@entry=0x0) at /build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1722
     #4  0x0000563cebeeff6a in target_read_alloc (ops=ops@entry=0x563cec758120, object=object@entry=TARGET_OBJECT_AUXV, annex=annex@entry=0x0) at /build/gdb-Nav6Es/gdb-10.1/gdb/target.c:1751
     #5  0x0000563cebc30630 in get_auxv_inferior_data (ops=0x563cec758120) at /build/gdb-Nav6Es/gdb-10.1/gdb/auxv.c:368
     #6  0x0000563cebc30c69 in target_auxv_search (ops=<optimized out>, match=match@entry=9, valp=valp@entry=0x7fff66a73158) at /build/gdb-Nav6Es/gdb-10.1/gdb/auxv.c:382
     #7  0x0000563cebe97881 in svr4_exec_displacement (displacementp=<synthetic pointer>) at /build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2577
     #8  svr4_relocate_main_executable () at /build/gdb-Nav6Es/gdb-10.1/gdb/solib-svr4.c:2960
     ...

control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134
control: found 993018 1:3.20.0-2.1


Hello,
I got recently remembered about this bug and patch.
So I try to find out what upstream thinks about this.

It can still be observed with current version in Trixie/testing.

Kind regards,
Bernhard