[RFA] GDB/624 - tbreak commands not executed when breakpoint hit
Michael Snyder
msnyder@redhat.com
Thu Aug 22 15:10:00 GMT 2002
Joel Brobecker wrote:
>
> As described in PR GDB/624:
>
> Using the small program from gdb.base/commands.exp, the following copy
> of a GDB sessions shows that commands associated to temporary
> breakpoints are not executed when the breakpoint is hit:
>
> (gdb) tbreak factorial
> Breakpoint 1 at 0x8048582: file ./gdb.base/run.c, line 77.
> (gdb) commands
> Type commands for when breakpoint 1 is hit, one per line.
> End with a line saying just "end".
> >silent
> >printf "factorial command-list executed\n"
> >cont
> >end
> (gdb) run 1
> Starting program: [...]/gdb.base/commands 1
> (gdb)
>
> The backtrace confirms that the program executed up to the factorial
> breakpoint, and then stopped.
>
> (gdb) bt
> #0 factorial (value=1) at ./gdb.base/run.c:77
> #1 0x0804855e in main (argc=2, argv=0xbffffa34, envp=0xbffffa40)
> at ./gdb.base/run.c:57
> #2 0x4005514f in __libc_start_main () from /lib/libc.so.6
> (gdb) p /x $pc
> $1 = 0x8048582 <<<--- $pc is equal to bp #1 address
>
> The expected output after the run command was:
>
> (gdb) run 1
> Starting program: [...]/gdb.base/commands 1
> factorial command-list executed
> 1
>
> Program exited normally.
> (gdb)
>
> The problem is that the breakpoint is deleted very early in the inferior
> stop handling, so the rest of the code does not have a chance to see
> that there was a temporary breakpoint there with a commands list to
> execute. To fix this, it is necessary to delay a bit the deletion of
> this breakpoint.
>
> This is what the attached patch does. There is a small side-effect,
> which I think should be ok, is that the after the temporary breakpoint
> is hit, there is a small period during which the breakpoint is still
> visible when doing ``info break''. The status report is disabled, and to
> be deleted at the next stop.
>
> I also attached an extra test in gdb.base/commands.exp.
>
> No new regression introduced on x86-linux.
>
> Ok to apply?
Joel, this implementation, with its use of delete_at_next_stop,
seems clumsy and, to be frank, scary. Instead, what if you just
made a temporary copy of the tbreak command-list (like you do for
GDB/622), then delete the breakpoint, and later execute the commands?
> 2002-07-31 Joel Brobecker <brobecker@gnat.com>
>
> * breakpoint.c (breakpoint_auto_delete): Do not delete temporary
> breakpoints to which a list of commands is attached. Mark them
> for deletion at the next stop instead. Also disable them to avoid
> hitting these breakpoints again.
> Move the part that deletes the to-be-deleted breakpoints before
> the part that deletes the temporary breakpoints, to avoid immediately
> deleting the temporary breakpoints that we just marked for deletion.
>
> 2002-07-31 Joel Brobecker <brobecker@gnat.com>
>
> * gdb.base/commands.exp (temporary_breakpoint_commands): New test.
>
> Thanks,
> --
> Joel
>
> ------------------------------------------------------------------------
>
> tbreak_commands.diffName: tbreak_commands.diff
> Type: Plain Text (text/plain)
More information about the Gdb-patches
mailing list