|
From: Matthias S. <zz...@ge...> - 2015-04-01 10:37:43
|
Hi! Sometimes I want to write a core-dump of the current status when I am in gdb attached to valgrind. But the gdb-command gcore does not work with vgdb. Does anyone know if it is possible to support this in a gdb remote agent? I did not get the full answer by looking in google. I found something about implementing access to proc-filesystem (or files in general) but I am not yet sure if this is the solution. Else I propose to add a monitor command to trigger the already implemented core-dump writing of valgrind. My experimental patch adds a monitor command "v.do core". It can be called multiple times and will just write multiple coredumps vgcore.PID.NO Does gdbserver know about the currently selected thread in gdb? I will post this patch the next days. Regards Matthias |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 20:03:56
|
On Wed, 2015-04-01 at 12:37 +0200, Matthias Schwarzott wrote: > Hi! > > Sometimes I want to write a core-dump of the current status when I am in > gdb attached to valgrind. > But the gdb-command gcore does not work with vgdb. ? Here is works (gdb 7.9) (gdb) gcore Saved corefile core.42000 (gdb) mo h general valgrind monitor commands: .... (the last command to show this gdb is connected to a V gdbsrv. However, it looks like the core dump might not be fully functional: (gdb) core core.42000 [New LWP 14340] warning: Error reading shared library list entry at 0x2118e0 Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 test () at trivialleak.c:8 8 leak = (void*)malloc( 1 ); (gdb) bt #0 test () at trivialleak.c:8 #1 0x0804840f in main () at trivialleak.c:12 (gdb) (the shared lib list entry looks bizarre to me). > Else I propose to add a monitor command to trigger the already > implemented core-dump writing of valgrind. It is intended to remove this capability to generate a core dump from inside valgrind, as this is fragile/missing some registers values/contains one single thread/... > My experimental patch adds a monitor command "v.do core". > It can be called multiple times and will just write multiple coredumps > vgcore.PID.NO > > Does gdbserver know about the currently selected thread in gdb? GDB typically has to indicate to gdbsrv on which thread to work. > > I will post this patch the next days. I think it would be better to see how gcore works (e.g. with multiple threads), and if needed fix the problems if they are some, rather than to invest on the valgrind core dump feature that it on its way out (if I have the time to cleanup in 3.11 the --db-attach that has been announced obsolete in 3.10) Philippe |
|
From: Matthias S. <zz...@ge...> - 2015-04-01 20:40:15
|
Am 01.04.2015 um 22:04 schrieb Philippe Waroquiers: > On Wed, 2015-04-01 at 12:37 +0200, Matthias Schwarzott wrote: >> Hi! >> >> Sometimes I want to write a core-dump of the current status when I am in >> gdb attached to valgrind. >> But the gdb-command gcore does not work with vgdb. > ? > Here is works (gdb 7.9) > (gdb) gcore > Saved corefile core.42000 > (gdb) mo h > general valgrind monitor commands: > .... > (the last command to show this gdb is connected to a V gdbsrv. Ok, I did not try again for some time. > However, it looks like the core dump might not be fully functional: > (gdb) core core.42000 > [New LWP 14340] > warning: Error reading shared library list entry at 0x2118e0 > Program terminated with signal SIGTRAP, Trace/breakpoint trap. > #0 test () at trivialleak.c:8 > 8 leak = (void*)malloc( 1 ); > (gdb) bt > #0 test () at trivialleak.c:8 > #1 0x0804840f in main () at trivialleak.c:12 > (gdb) > > > (the shared lib list entry looks bizarre to me). > >> Else I propose to add a monitor command to trigger the already >> implemented core-dump writing of valgrind. > It is intended to remove this capability to generate a core > dump from inside valgrind, as this is fragile/missing some registers > values/contains one single thread/... What does that mean for valgrind alone? Will you really remove writing core-dumps from the normal valgrind signal handlers? How should it react on signals that normally write core-dumps? Regards Matthias |
|
From: Philippe W. <phi...@sk...> - 2015-04-01 21:03:11
|
On Wed, 2015-04-01 at 22:40 +0200, Matthias Schwarzott wrote: > > (the last command to show this gdb is connected to a V gdbsrv. > Ok, I did not try again for some time. Testing/validation/bug reports (and bug fixes if needed) welcome :). > >> Else I propose to add a monitor command to trigger the already > >> implemented core-dump writing of valgrind. > > It is intended to remove this capability to generate a core > > dump from inside valgrind, as this is fragile/missing some registers > > values/contains one single thread/... > What does that mean for valgrind alone? Will you really remove writing > core-dumps from the normal valgrind signal handlers? Ouch, no. I confused 2 pieces of code. > How should it react on signals that normally write core-dumps? It will continue to core dump as of today, because this core dump code will stay :). Philippe |