Re: [RFA] GDB/624 - tbreak commands not executed when breakpoint hit

[Michael Snyder <msnyder at redhat dot com>]

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)