[rfc] Print solib events in mi-mode

[Andrew Cagney]

> We handled this problem by creating a new breakpoint command,  "future-break" (short: "fb", done in MI as "-break-insert -f ...").   This pushes the logic down in to gdb.  On the one hand, it's expensive  to have gdb trying to set this breakpoint for every shared library that  comes in (when you have a lot of big shared libraries like we do on  MacOS X), but at the same time if the IDE is responsible for setting  breakpoints in shared libraries then you'll have to stop on each solib  add event to set those breakpoints before anything runs...
> 
> You can see all of this in the above sample; breakpoint #1 was a  file:line breakpoint, which was in SKTGraphic.ob.  When SKTGraphic.ob  was paged in (this is a project using ZeroLink, so each source file is  a separate objfile, pulled in at run-time as needed), the breakpoint  was set by gdb.
> 
> 
> 
> The future-break patches were posted at least once in the past along  with the save-breakpoints command; I can find a URL ref if anyone  cares. 

Yes, Tom Tromey observed:
http://sources.redhat.com/ml/gdb-patches/2001-12/msg00152.html
> 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.

enjoy,
Andrew