"tbreak" and "commands" commands...

"tbreak" and "commands" commands...

[Joel Brobecker]

Hello,

According to the documentation, we should be able to associate a list
of commands to execute when the inferior hits a temporary breakpoint.
It currently does not seem to be the case. Is there a limitation in this
area, or is this a regression (in which case I'll be happy to work on
this)?

Here is a small copy of a simple session:
<<
GNU gdb 2002-07-26-cvs
[snip]
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) tbreak test.c:8
Breakpoint 1 at 0x804854f: file test.c, line 8.
(gdb) command
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>printf "+++ breakpoint hit\n"
>continue
>end
(gdb) run
Starting program: /nfs/paris/paris.a/brobecke/act/report/gdb/B726-014__cont_abbrev/test.bonn 
main () at test.c:8
8           printf ("Hello world.\n");
(gdb) 
>>

As you see, the inferior stopped at breakpoint 1, but the command list was
not executed...

Thanks,
-- 
Joel

Re: "tbreak" and "commands" commands...

[William A. Gatliff]

Joel:


Does it work with "break" instead of "tbreak"?  I've never tried it
with tbreak, but "break" works in 5.1--- I use it a lot.

b.g.

On Fri, Jul 26, 2002 at 11:54:06AM -0700, Joel Brobecker wrote:
> Hello,
> 
> According to the documentation, we should be able to associate a list
> of commands to execute when the inferior hits a temporary breakpoint.
> It currently does not seem to be the case. Is there a limitation in this
> area, or is this a regression (in which case I'll be happy to work on
> this)?
> 
> Here is a small copy of a simple session:
> <<
> GNU gdb 2002-07-26-cvs
> [snip]
> This GDB was configured as "i686-pc-linux-gnu"...
> (gdb) tbreak test.c:8
> Breakpoint 1 at 0x804854f: file test.c, line 8.
> (gdb) command
> Type commands for when breakpoint 1 is hit, one per line.
> End with a line saying just "end".
> >printf "+++ breakpoint hit\n"
> >continue
> >end
> (gdb) run
> Starting program: /nfs/paris/paris.a/brobecke/act/report/gdb/B726-014__cont_abbrev/test.bonn 
> main () at test.c:8
> 8           printf ("Hello world.\n");
> (gdb) 
> >>
> 
> As you see, the inferior stopped at breakpoint 1, but the command list was
> not executed...
> 
> Thanks,
> -- 
> Joel

-- 
Bill Gatliff
bgat@billgatliff.com

Re: "tbreak" and "commands" commands...

[Joel Brobecker]

> Does it work with "break" instead of "tbreak"?  I've never tried it
> with tbreak, but "break" works in 5.1--- I use it a lot.

Yes, it works with regular breakpoints. It's only with temporary
breakpoints that it does not work. I suspect that the temporary
breakpoint with its command list is deleted before the command-list gets
a chance to be executed.  I would like to know if this is the intended
behavior (in which case I think GDB should refuse to add the command),
or if this is a bug.

-- 
Joel

Re: "tbreak" and "commands" commands...

[Fernando Nasser]

Joel Brobecker wrote:
> 
> > Does it work with "break" instead of "tbreak"?  I've never tried it
> > with tbreak, but "break" works in 5.1--- I use it a lot.
> 
> Yes, it works with regular breakpoints. It's only with temporary
> breakpoints that it does not work. I suspect that the temporary
> breakpoint with its command list is deleted before the command-list gets
> a chance to be executed.  I would like to know if this is the intended
> behavior (in which case I think GDB should refuse to add the command),
> or if this is a bug.
> 

Yes, it is a bug anyway.  We should either refuse or handle the
commands.

Is there any specific reason you want to delete the breakpoint?
You can just disable it as part of the commands.

Re: "tbreak" and "commands" commands...

[Joel Brobecker]

> Yes, it is a bug anyway.  We should either refuse or handle the
> commands.

OK. I think the right thing to do now is to open a PR. I forgot to
mention it in my first message, but I had consulted the database before
sending it.

> Is there any specific reason you want to delete the breakpoint?
> You can just disable it as part of the commands.

I can't say for sure, because I am not the one who came across this odd
behavior. I was just asked why it id not work...

But I think I have an idea. I think they (the persons who found this
problem) are using a script to do some regression testing. They know the
code with go through certain locations in a certain order. So they
put temporary breakpoints one after the other. They make them temporary
in order for the previous breakpoints not to interfere during the
execution.

I don't have a problem rejecting commands on temporary breakpoints.
They already use the work-around you suggest of disabling the breakpoint
inside the command, but this is a light pain, and may also be prone to
error.

It seems that there we don't know of any reason at the moment why
commands could not work with temporary breakpoints. So I will see if I
can fix that. If it turns out to be too complicated, then we can change
GDB to refuse commands with temporary breakpoints. Does it sound
reasonable?

-- 
Joel

Re: "tbreak" and "commands" commands...

[Fernando Nasser]

Joel Brobecker wrote:
> 
> It seems that there we don't know of any reason at the moment why
> commands could not work with temporary breakpoints. So I will see if I
> can fix that. If it turns out to be too complicated, then we can change
> GDB to refuse commands with temporary breakpoints. Does it sound
> reasonable?
> 

It certainly does.

Thank you for the report and for looking into fixing it.

Regards,
Fernando