From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9052 invoked by alias); 22 Aug 2002 22:07:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9045 invoked from network); 22 Aug 2002 22:07:38 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 22 Aug 2002 22:07:38 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA07494; Thu, 22 Aug 2002 15:01:46 -0700 (PDT) Message-ID: <3D6560A2.BEA0B7DD@redhat.com> Date: Thu, 22 Aug 2002 15:10:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] GDB/624 - tbreak commands not executed when breakpoint hit References: <20020731200936.GL683@gnat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00725.txt.bz2 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 > > * 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 > > * gdb.base/commands.exp (temporary_breakpoint_commands): New test. > > Thanks, > -- > Joel > > ------------------------------------------------------------------------ > > tbreak_commands.diffName: tbreak_commands.diff > Type: Plain Text (text/plain)