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

[Joel Brobecker <brobecker@gnat.com>]

> 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