This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] dynamic printf
On 05/17/2012 02:56 AM, Tom Tromey wrote:
> In this particular case, though, I think you could do it by just having
> the 'printf' invocation not be 'commands' stuck onto a breakpoint, but
> instead a per-dprintf method that is run at the appropriate moment, a la
> the Python 'Breakpoint.stop' method.
I agree.
I can't be within bkpt_ops->check_status (even though that'd be hacky),
as I think you'd want to support conditions on dprintf, and those are
checked after check_status is consulted.
Another question is, is the user supposed to set commands on dprintf? Currently
you get:
(gdb) dprintf 36, "hello"
Dprintf 2 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36.
(gdb) info breakpoints
2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36
printf "hello"
continue
(gdb) commands 2
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "world"
>end
(gdb) info breakpoints
Num Type Disp Enb Address What
2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36
breakpoint already hit 1 time
echo "world"
Another related weekness of the current implementation is that a regular
breakpoint that should cause a stop set at the same address as a dprintf
no longer works correctly, due to the forced "continue". E.g.,
(gdb) dprintf 36, "hello"
Dprintf 2 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36.
(gdb) b 36
Note: breakpoint 2 also set at pc 0x4005e0.
Breakpoint 3 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36
printf "hello"
continue
3 breakpoint keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36
(gdb) b 39
Breakpoint 4 at 0x40060e: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 39.
(gdb) c
Continuing.
Breakpoint 2, main (argc=1, argv=0x7fffffffdd48) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36
36 printf ("kickoff\n");
hellokickoff
also to stderr
Breakpoint 4, main (argc=1, argv=0x7fffffffdd48) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:39
39 foo (loc++);
(gdb)
Breakpoint 3 causes a stop, but GDB starts by running the commands of breakpoint 2 (the dprintf),
just because it has a lower number, and that includes the "continue", so breakpoint 3 is lost.
A similar issue happens with more than one dprintf installed on the same location -- only one
would run. Multiple dprintfs on the same location would be useful when you set different
conditions on each (like with multiple breakpoints on the same location).
--
Pedro Alves