fix break, not add future-break

fix break, not add future-break

[Andrew Cagney]

Hello,

There is a change kicking around that adds a new `future-break' command. 
  It started life as `save breakpoints':

http://sources.redhat.com/ml/gdb-patches/2001-12/msg00108.html

that received a prompt review response.  Unfortunatly, instead of simply 
addressing the relevant issues, it turned into a future-break jumbo patch:

http://sources.redhat.com/ml/gdb-patches/2001-12/msg00296.html

At the time Tom Tromey made the point:

> Klee> The 'future-break' command allows one to specify a breakpoint
> Klee> that starts off as 'shlib_disabled' instead of generating an
> Klee> error if it can't be set immediately.
> 
> Klee> I'm not entirely happy with the future-break command, and
> Klee> particularly with its interaction with the save-breakpoints
> Klee> mechanism (if you set a breakpoint that is in a shared library
> Klee> after shared libraries have been loaded, you have to remember to
> Klee> use the future-break command, not the break command).
> 
> Doesn't this mean that programs like Insight would be best advised to
> *only* set future breakpoints?  In that case let's just add the
> functionality directly to the existing breakpoint commands.
http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html

(the original contributor never responded.)

I think Tom is right.  Rather than adding a new contextually sensitive 
command (`don't mode me in'), GDB should `fix' the existing break 
command.  Just like the GUI, normal users are going to be confused by 
this unnecessary choice.  Why, after all, should a user have to learn a 
different command just so that they can set breakpoints on an unloaded 
shared library?

Further, if GUI implementors want specific break command semantics, then 
they should be extending the MI interface and not perverting the CLI.

I'd like to propose that break be modified so that it behaves something 
like:

	(gdb) break printf.c:printf
	File "printf.c" not currently known, set breakpoint anyway?

And then later:

	(gdb) c
	Loading shared library libc.so.
	Enabling breakpoint "printf.c:printf" at ....

For edge conditions:

- If the executable is re-started or re-loaded, all breakpoints get 
marked as `unloaded' (or what ever shlib breakpoints are ment to get set 
to) and then get enabled as they become valid.
- If it turns out that a breakpoint is never enabled then `oops'.
- If it turns out that a breakpoint wasn't valid, issue a warning and 
disable it for the remainder of that session (?).
- If a breakpoint isn't valid in a script, then issue a warning and add 
it anyway.  Who's it going to hurt?
- if the executable being debugged is changed then, well, do what ever 
the current code does.

Andrew

Re: fix break, not add future-break

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:

Andrew> I'd like to propose that break be modified so that it behaves
Andrew> something like:
Andrew> 	(gdb) break printf.c:printf
Andrew> 	File "printf.c" not currently known, set breakpoint anyway?

For Insight I think it would be useful to have a version of the
command (or a flag, e.g. "break -future") that never asks.  I imagine
that's true of other GUIs as well, though you'd have to ask those more
familiar with them.

The scenario I'm thinking of is saving breakpoints.  Right now we save
all the breakpoints in the session.  When reloading breakpoints, any
breakpoint that isn't immediately valid is discarded.  This is a major
problem for me (and presumably others), since I do a lot of debugging
of code in shared libraries -- meaning that many of my breakpoints are
lost from session to session.

For breakpoints the user enters by hand, asking seems like a nice
idea.

Tom

Re: fix break, not add future-break

[Andrew Cagney]

> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
> Andrew> I'd like to propose that break be modified so that it behaves
> Andrew> something like:
> Andrew> 	(gdb) break printf.c:printf
> Andrew> 	File "printf.c" not currently known, set breakpoint anyway?
> 
> For Insight I think it would be useful to have a version of the
> command (or a flag, e.g. "break -future") that never asks.  I imagine
> that's true of other GUIs as well, though you'd have to ask those more
> familiar with them.
> 
> The scenario I'm thinking of is saving breakpoints.  Right now we save
> all the breakpoints in the session.  When reloading breakpoints, any
> breakpoint that isn't immediately valid is discarded.  This is a major
> problem for me (and presumably others), since I do a lot of debugging
> of code in shared libraries -- meaning that many of my breakpoints are
> lost from session to session.

Yep.  If the breakpoint is comming from a script, just assume `user 
knows best' and add them regardless.

> For breakpoints the user enters by hand, asking seems like a nice
> idea.
> 
> Tom

Andrew

Re: fix break, not add future-break

[Eli Zaretskii]

> Date: Tue, 11 Mar 2003 10:13:33 -0500
> From: Andrew Cagney <ac131313@redhat.com>
> 
> I'd like to propose that break be modified so that it behaves something 
> like:
> 
> 	(gdb) break printf.c:printf
> 	File "printf.c" not currently known, set breakpoint anyway?
> 
> And then later:
> 
> 	(gdb) c
> 	Loading shared library libc.so.
> 	Enabling breakpoint "printf.c:printf" at ....

Sounds like a good idea to me.

Re: fix break, not add future-break

[Jim Ingham]

We talked about this a bit here.  Jason was worried that users might 
find getting an extra prompt when they just mistyped annoying.  It is 
certainly a pretty big change in UI, and will be jarring to old hands 
for a while.  On the other hand, I kind of like this better than having 
to remember to type another command to get shared-library breakpoints 
to take.

Working with programmatic interfaces is different, however.  We added a 
-f flag to -break-insert to turn on the "future" behavior.  I think 
calling it out explicitly like this is better for a programmatic 
interface, since for a driving program it is better to be able to ask 
for exactly what you want, than asking for something more general and 
then having to deal modally with the possible responses to a more 
general request...

Jim

On Thursday, March 13, 2003, at 12:36  PM, 
gdb-digest-help@sources.redhat.com wrote:

>> Date: Tue, 11 Mar 2003 10:13:33 -0500
>> From: Andrew Cagney <ac131313@redhat.com>
>>
>> I'd like to propose that break be modified so that it behaves 
>> something
>> like:
>>
>> 	(gdb) break printf.c:printf
>> 	File "printf.c" not currently known, set breakpoint anyway?
>>
>> And then later:
>>
>> 	(gdb) c
>> 	Loading shared library libc.so.
>> 	Enabling breakpoint "printf.c:printf" at ....
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer