Re: [PATCH v2] dynamic printf

[Pedro Alves <palves at redhat dot com>]

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