fix break, not add future-break

[Andrew Cagney <ac131313@redhat.com>]

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