[rfc] Print solib events in mi-mode

[rfc] Print solib events in mi-mode

[Kris Warkentin]

What do you think of something like this?  When stop-on-solib-events is set,
this will print the reason as being a shared-lib-event.

Our Eclipse team wants to be able to set breakpoints in shared libraries
that aren't loaded yet.  If they get notification of shlib-events, then they
can re-examine the list of loaded libraries and set any breakpoints that
have been enabled in the project's libs.

cheers,

Kris

$ cvs diff -u breakpoint.c
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.125
diff -u -r1.125 breakpoint.c
--- breakpoint.c        2 Jul 2003 16:24:00 -0000       1.125
+++ breakpoint.c        8 Jul 2003 20:32:50 -0000
@@ -2039,8 +2039,10 @@
       /* Did we stop because the user set the stop_on_solib_events
         variable?  (If so, we report this as a generic, "Stopped due
         to shlib event" message.) */
-      printf_filtered ("Stopped due to shared library event\n");
-      return PRINT_NOTHING;
+      ui_out_text (uiout, "\nShared library event ");
+      if (ui_out_is_mi_like_p (uiout))
+       ui_out_field_string (uiout, "reason", "shared-lib-event");
+      return PRINT_SRC_ONLY;
       break;

     case bp_thread_event:

Re: [rfc] Print solib events in mi-mode

[Andrew Cagney]

> What do you think of something like this?  When stop-on-solib-events is set,
> this will print the reason as being a shared-lib-event.
> 
> Our Eclipse team wants to be able to set breakpoints in shared libraries
> that aren't loaded yet.  If they get notification of shlib-events, then they
> can re-examine the list of loaded libraries and set any breakpoints that
> have been enabled in the project's libs.

See: [RFC] add 'save-breakpoints' command
http://sources.redhat.com/ml/gdb-patches/2001-12/threads.html#00114
(but check for other related threads).

The resolution was interesting, instead of adding a new command, modify 
the existing command so that it would add breakpoints that would be 
automatically enabled later.

Andrew

(although the patch is probably also useful)

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

Actually, I had looked at those and some other related threads.  I suggested
to our Eclipse guys that it would probably be easy for them to just
implement it in the IDE (since all the apps and libs are already projects
under IDE control) using the stop-on-solib-event mechanism.  They countered
that there was no mi feedback on whether an stop was solib related, hence my
patch.

If there's no objection to the output this provides, I wouldn't mind
applying it. MI-ification is generally a good thing right?  Is there
somewhere I should document this as well?

cheers,

Kris

----- Original Message ----- 
From: "Andrew Cagney" <ac131313@redhat.com>
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: "Gdb@Sources.Redhat.Com" <gdb@sources.redhat.com>
Sent: Tuesday, July 08, 2003 5:02 PM
Subject: Re: [rfc] Print solib events in mi-mode


> > What do you think of something like this?  When stop-on-solib-events is
set,
> > this will print the reason as being a shared-lib-event.
> >
> > Our Eclipse team wants to be able to set breakpoints in shared libraries
> > that aren't loaded yet.  If they get notification of shlib-events, then
they
> > can re-examine the list of loaded libraries and set any breakpoints that
> > have been enabled in the project's libs.
>
> See: [RFC] add 'save-breakpoints' command
> http://sources.redhat.com/ml/gdb-patches/2001-12/threads.html#00114
> (but check for other related threads).
>
> The resolution was interesting, instead of adding a new command, modify
> the existing command so that it would add breakpoints that would be
> automatically enabled later.
>
> Andrew
>
> (although the patch is probably also useful)
>
>
>

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote:
> Actually, I had looked at those and some other related threads.  I suggested
> to our Eclipse guys that it would probably be easy for them to just
> implement it in the IDE (since all the apps and libs are already projects
> under IDE control) using the stop-on-solib-event mechanism.  They countered
> that there was no mi feedback on whether an stop was solib related, hence my
> patch.
> 
> If there's no objection to the output this provides, I wouldn't mind
> applying it. MI-ification is generally a good thing right?  Is there
> somewhere I should document this as well?

TBH, I'd rather see load catchpoints implemented and MI-ified for
solib-svr4.c.  The natural implementation returns more useful
information, namely what libraries were loaded or unloaded.  It should
be easy but it's never trickled to the top of anyone's TODO.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote:
> > Actually, I had looked at those and some other related threads.  I
suggested
> > to our Eclipse guys that it would probably be easy for them to just
> > implement it in the IDE (since all the apps and libs are already
projects
> > under IDE control) using the stop-on-solib-event mechanism.  They
countered
> > that there was no mi feedback on whether an stop was solib related,
hence my
> > patch.
> >
> > If there's no objection to the output this provides, I wouldn't mind
> > applying it. MI-ification is generally a good thing right?  Is there
> > somewhere I should document this as well?
>
> TBH, I'd rather see load catchpoints implemented and MI-ified for
> solib-svr4.c.  The natural implementation returns more useful
> information, namely what libraries were loaded or unloaded.  It should
> be easy but it's never trickled to the top of anyone's TODO.

What about solib-events on non-svr4 systems?  QNX is implementing the CDT
for Eclipse and we'd like to have equal functionality across platforms.

cheers,

Kris

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote:
> > On Wed, Jul 09, 2003 at 08:24:28AM -0400, Kris Warkentin wrote:
> > > Actually, I had looked at those and some other related threads.  I
> suggested
> > > to our Eclipse guys that it would probably be easy for them to just
> > > implement it in the IDE (since all the apps and libs are already
> projects
> > > under IDE control) using the stop-on-solib-event mechanism.  They
> countered
> > > that there was no mi feedback on whether an stop was solib related,
> hence my
> > > patch.
> > >
> > > If there's no objection to the output this provides, I wouldn't mind
> > > applying it. MI-ification is generally a good thing right?  Is there
> > > somewhere I should document this as well?
> >
> > TBH, I'd rather see load catchpoints implemented and MI-ified for
> > solib-svr4.c.  The natural implementation returns more useful
> > information, namely what libraries were loaded or unloaded.  It should
> > be easy but it's never trickled to the top of anyone's TODO.
> 
> What about solib-events on non-svr4 systems?  QNX is implementing the CDT
> for Eclipse and we'd like to have equal functionality across platforms.

I picked on solib-svr4 because it's the one normally found lacking.  At
least one of the solib backends already does this - probably SOM?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote:
> > > TBH, I'd rather see load catchpoints implemented and MI-ified for
> > > solib-svr4.c.  The natural implementation returns more useful
> > > information, namely what libraries were loaded or unloaded.  It should
> > > be easy but it's never trickled to the top of anyone's TODO.
> >
> > What about solib-events on non-svr4 systems?  QNX is implementing the
CDT
> > for Eclipse and we'd like to have equal functionality across platforms.
>
> I picked on solib-svr4 because it's the one normally found lacking.  At
> least one of the solib backends already does this - probably SOM?

So you're saying that you're not receptive to this patch but you'd consider
a svr4 patch for the load catchpoints?

Kris

Re: [rfc] Print solib events in mi-mode

[Kevin Buettner]

On Jul 9,  1:29pm, Kris Warkentin wrote:

> > On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote:
> > > > TBH, I'd rather see load catchpoints implemented and MI-ified for
> > > > solib-svr4.c.  The natural implementation returns more useful
> > > > information, namely what libraries were loaded or unloaded.  It should
> > > > be easy but it's never trickled to the top of anyone's TODO.
> > >
> > > What about solib-events on non-svr4 systems?  QNX is implementing the
> CDT
> > > for Eclipse and we'd like to have equal functionality across platforms.
> >
> > I picked on solib-svr4 because it's the one normally found lacking.  At
> > least one of the solib backends already does this - probably SOM?
> 
> So you're saying that you're not receptive to this patch but you'd consider
> a svr4 patch for the load catchpoints?

If it could be moved out to solib.c, I'd be receptive to it.  I'm also
willing to look at a patch which modifies solib-svr4.c, but I'd prefer
one which handles all off the solib backends in one fell swoop.

Kevin

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> > > On Wed, Jul 09, 2003 at 11:39:26AM -0400, Kris Warkentin wrote:
> > > > > TBH, I'd rather see load catchpoints implemented and MI-ified for
> > > > > solib-svr4.c.  The natural implementation returns more useful
> > > > > information, namely what libraries were loaded or unloaded.  It
should
> > > > > be easy but it's never trickled to the top of anyone's TODO.
> > > >
> > > > What about solib-events on non-svr4 systems?  QNX is implementing
the
> > CDT
> > > > for Eclipse and we'd like to have equal functionality across
platforms.
> > >
> > > I picked on solib-svr4 because it's the one normally found lacking.
At
> > > least one of the solib backends already does this - probably SOM?
> >
> > So you're saying that you're not receptive to this patch but you'd
consider
> > a svr4 patch for the load catchpoints?
>
> If it could be moved out to solib.c, I'd be receptive to it.  I'm also
> willing to look at a patch which modifies solib-svr4.c, but I'd prefer
> one which handles all off the solib backends in one fell swoop.

The patch is for breakpoint.c.  It's in the print_it_typical() function
which handles output when a breakpoint is hit.  I'm not sure how I would put
this into solib.c.

cheers,

Kris

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

Someone just pointed something out to me.  "set stop-on-solib-events 1" is
NOT enable-load-catchpoint or anything else.  Yes, those things should exist
for all solib platforms but the bottom line is that stop-on-solib-events is
not currently mi-enabled and it should be.

I want to make that command result in proper mi output, regardless of any
other things which might be implemented in the future.

cheers,

Kris

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote:
> Someone just pointed something out to me.  "set stop-on-solib-events 1" is
> NOT enable-load-catchpoint or anything else.  Yes, those things should exist
> for all solib platforms but the bottom line is that stop-on-solib-events is
> not currently mi-enabled and it should be.
> 
> I want to make that command result in proper mi output, regardless of any
> other things which might be implemented in the future.

And I want load catchpoints fixed, so that stop-on-solib-events is
NEVER MI-enabled, so that it can be removed instead of supported for
years.  It is in every way inferior to catchpoints.  That was my point.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote:
> > Someone just pointed something out to me.  "set stop-on-solib-events 1"
is
> > NOT enable-load-catchpoint or anything else.  Yes, those things should
exist
> > for all solib platforms but the bottom line is that stop-on-solib-events
is
> > not currently mi-enabled and it should be.
> >
> > I want to make that command result in proper mi output, regardless of
any
> > other things which might be implemented in the future.
>
> And I want load catchpoints fixed, so that stop-on-solib-events is
> NEVER MI-enabled, so that it can be removed instead of supported for
> years.  It is in every way inferior to catchpoints.  That was my point.

Well I want an ice cream bar so I'm going to go get one. :-P

Alright then.  I see that SOM and PA64 both implement
SOLIB_CREATE_CATCH_*LOAD_HOOK and most everyone else just errors out if you
try.  Should we be adding these functions to the target_so_ops vector?  Does
every target that supports solibs build solib.c?  If so, we could tweak the
defines to use the vector and have a default implementation that prints an
error.  That way solib-svr4 and friends can implement these functions in the
backend.

????

Kris

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 02:21:28PM -0400, Kris Warkentin wrote:
> > On Wed, Jul 09, 2003 at 02:02:00PM -0400, Kris Warkentin wrote:
> > > Someone just pointed something out to me.  "set stop-on-solib-events 1"
> is
> > > NOT enable-load-catchpoint or anything else.  Yes, those things should
> exist
> > > for all solib platforms but the bottom line is that stop-on-solib-events
> is
> > > not currently mi-enabled and it should be.
> > >
> > > I want to make that command result in proper mi output, regardless of
> any
> > > other things which might be implemented in the future.
> >
> > And I want load catchpoints fixed, so that stop-on-solib-events is
> > NEVER MI-enabled, so that it can be removed instead of supported for
> > years.  It is in every way inferior to catchpoints.  That was my point.
> 
> Well I want an ice cream bar so I'm going to go get one. :-P

Curse you, now I want ice cream.

> Alright then.  I see that SOM and PA64 both implement
> SOLIB_CREATE_CATCH_*LOAD_HOOK and most everyone else just errors out if you
> try.  Should we be adding these functions to the target_so_ops vector?  Does
> every target that supports solibs build solib.c?  If so, we could tweak the
> defines to use the vector and have a default implementation that prints an
> error.  That way solib-svr4 and friends can implement these functions in the
> backend.
> 
> ????

That's not really the problem - the breakpoint is already there, it's
the same breakpoint we stop at for stop-on-solib-events.  The real
trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT
and SOLIB_LOADED_LIBRARY_PATHNAME.  The model has to change a little
since more than one library can be reported at once in the svr4 model.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> That's not really the problem - the breakpoint is already there, it's
> the same breakpoint we stop at for stop-on-solib-events.  The real
> trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT
> and SOLIB_LOADED_LIBRARY_PATHNAME.  The model has to change a little
> since more than one library can be reported at once in the svr4 model.

Well, SOLIB_LOADED_LIBRARY_PATHNAME is only used twice.  Once it just fills
a string (triggered_dll_pathname) which is only used for printing.
Therefore we could return a comma separated list or something pretty like
that.

The other is just to compare against a dll_pathname so we could get away
with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend
check through the list for libname.

Okay...that seems reasonable.  Another question: since we've already got a
solib breakpoint set in svr4, we don't need to call
create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do.
Can you have multiple types associated with a single break or do we just set
another at the same address?

cheers,

Kris

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 03:13:05PM -0400, Kris Warkentin wrote:
> > That's not really the problem - the breakpoint is already there, it's
> > the same breakpoint we stop at for stop-on-solib-events.  The real
> > trick is going to be reporting the events - SOLIB_HAVE_LOAD_EVENT
> > and SOLIB_LOADED_LIBRARY_PATHNAME.  The model has to change a little
> > since more than one library can be reported at once in the svr4 model.
> 
> Well, SOLIB_LOADED_LIBRARY_PATHNAME is only used twice.  Once it just fills
> a string (triggered_dll_pathname) which is only used for printing.
> Therefore we could return a comma separated list or something pretty like
> that.
> 
> The other is just to compare against a dll_pathname so we could get away
> with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend
> check through the list for libname.

Sure.  Or return a list and let solib.c sort between 'em.

> Okay...that seems reasonable.  Another question: since we've already got a
> solib breakpoint set in svr4, we don't need to call
> create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do.
> Can you have multiple types associated with a single break or do we just set
> another at the same address?

It should be multiple "catchpoints", and inserting catchpoints would do
nothing to the target.  This may require violence to the breakpoint
system, which is why I haven't done it yet :(

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> > The other is just to compare against a dll_pathname so we could get away
> > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the
backend
> > check through the list for libname.
>
> Sure.  Or return a list and let solib.c sort between 'em.

Do you think these functions should be in current_target_so_ops?

> > Okay...that seems reasonable.  Another question: since we've already got
a
> > solib breakpoint set in svr4, we don't need to call
> > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do.
> > Can you have multiple types associated with a single break or do we just
set
> > another at the same address?
>
> It should be multiple "catchpoints", and inserting catchpoints would do
> nothing to the target.  This may require violence to the breakpoint
> system, which is why I haven't done it yet :(

You're suggesting a list of gdb "actions" associated with a single
breakpoint on the target? IE, test for a condition, execute a catch, check
solibs on the target, etc.?

Kris

Re: [rfc] Print solib events in mi-mode

[Daniel Jacobowitz]

On Wed, Jul 09, 2003 at 04:00:52PM -0400, Kris Warkentin wrote:
> > > The other is just to compare against a dll_pathname so we could get away
> > > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the
> backend
> > > check through the list for libname.
> >
> > Sure.  Or return a list and let solib.c sort between 'em.
> 
> Do you think these functions should be in current_target_so_ops?

Hmm... yes, probably.

> > > Okay...that seems reasonable.  Another question: since we've already got
> a
> > > solib breakpoint set in svr4, we don't need to call
> > > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do.
> > > Can you have multiple types associated with a single break or do we just
> set
> > > another at the same address?
> >
> > It should be multiple "catchpoints", and inserting catchpoints would do
> > nothing to the target.  This may require violence to the breakpoint
> > system, which is why I haven't done it yet :(
> 
> You're suggesting a list of gdb "actions" associated with a single
> breakpoint on the target? IE, test for a condition, execute a catch, check
> solibs on the target, etc.?

No, a set of catchpoints (type bp_catch_load), one for each condition. 
But inserting or removing them would do nothing on svr4; the breakpoint
is always inserted.  When we hit that breakpoint we would check for all
catch_load and catch_unloads.

This is part of the needed breakpoint overhaul.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] Print solib events in mi-mode

[Andrew Cagney]

>> > > I picked on solib-svr4 because it's the one normally found lacking.
> 
> At
> 
>> > > least one of the solib backends already does this - probably SOM?
> 
>> >
>> > So you're saying that you're not receptive to this patch but you'd
> 
> consider
> 
>> > a svr4 patch for the load catchpoints?
> 
>>
>> If it could be moved out to solib.c, I'd be receptive to it.  I'm also
>> willing to look at a patch which modifies solib-svr4.c, but I'd prefer
>> one which handles all off the solib backends in one fell swoop.
> 
> 
> The patch is for breakpoint.c.  It's in the print_it_typical() function
> which handles output when a breakpoint is hit.  I'm not sure how I would put
> this into solib.c.

It's also for a different problem.  MIing a few more stop reasons 
wouldn't hurt.

Andrew

Re: [rfc] Print solib events in mi-mode

[Jason Molenda]

Hi Kris,

On Tuesday, July 8, 2003, at 1:36 PM, Kris Warkentin wrote:

> What do you think of something like this?  When stop-on-solib-events  
> is set,
> this will print the reason as being a shared-lib-event.

For what it's worth, at Apple we do something very similar.  This  
section of code in breakpoint.c reads:

     case bp_shlib_event:
       /* Did we stop because the user set the stop_on_solib_events
          variable?  (If so, we report this as a generic, "Stopped due
          to shlib event" message.) */
       if (interpreter_p && strncmp (interpreter_p, "mi", 2) == 0)
         ui_out_field_string (uiout, "reason", "shlib-event");
       else
         printf_filtered ("Stopped due to shared library event\n");
       return PRINT_NOTHING;
       break;

For the case where stop-on-shlibs-added is not set, we have an MI  
notification that gets posted each time a shared library is loaded.  It  
looks like this to the UI side:

=shlibs-updated
=shlibs-added,shlib-info=[num="54",name="SKTDrawDocument.ob",kind="- 
",dyld-addr="0x271000",reason="dyld",requested- 
state="?",state="N",path="/Developer/Examples/AppKit/Sketch/build/ 
Sketch.build/Sketch  
(Upgraded).build/Objects-normal/ppc/ 
SKTDrawDocument.ob",slide="",addr="",prefix=""]
~"Re-enabling shared library breakpoints: 1\n"
<-  
=shlibs-added,shlib-info=[num="55",name="SKTGraphic.ob",kind="-",dyld- 
addr="0x28a000",reason="dyld",requested-state="?",state="N",path="/ 
Developer/Examples/AppKit/Sketch/build/Sketch.build/Sketch  
(Upgraded).build/Objects-normal/ppc/ 
SKTGraphic.ob",slide="",addr="",prefix=""]


In our case, this message is emitted by one of our arch-specific files,  
macosx/macosx-nat-dyld.c, in a function called macosx_solib_add().


> Our Eclipse team wants to be able to set breakpoints in shared  
> libraries
> that aren't loaded yet.  If they get notification of shlib-events,  
> then they
> can re-examine the list of loaded libraries and set any breakpoints  
> that
> have been enabled in the project's libs.

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.

Jason

>
> cheers,
>
> Kris
>
> $ cvs diff -u breakpoint.c
> Index: breakpoint.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/breakpoint.c,v
> retrieving revision 1.125
> diff -u -r1.125 breakpoint.c
> --- breakpoint.c        2 Jul 2003 16:24:00 -0000       1.125
> +++ breakpoint.c        8 Jul 2003 20:32:50 -0000
> @@ -2039,8 +2039,10 @@
>        /* Did we stop because the user set the stop_on_solib_events
>          variable?  (If so, we report this as a generic, "Stopped due
>          to shlib event" message.) */
> -      printf_filtered ("Stopped due to shared library event\n");
> -      return PRINT_NOTHING;
> +      ui_out_text (uiout, "\nShared library event ");
> +      if (ui_out_is_mi_like_p (uiout))
> +       ui_out_field_string (uiout, "reason", "shared-lib-event");
> +      return PRINT_SRC_ONLY;
>        break;
>
>      case bp_thread_event:
>
>

Re: [rfc] Print solib events in mi-mode

[Kris Warkentin]

> For the case where stop-on-shlibs-added is not set, we have an MI
> notification that gets posted each time a shared library is loaded.  It
> looks like this to the UI side:
>
> =shlibs-updated
> =shlibs-added,shlib-info=[num="54",name="SKTDrawDocument.ob",kind="-
> ",dyld-addr="0x271000",reason="dyld",requested-
> state="?",state="N",path="/Developer/Examples/AppKit/Sketch/build/
> Sketch.build/Sketch
> (Upgraded).build/Objects-normal/ppc/
> SKTDrawDocument.ob",slide="",addr="",prefix=""]
> ~"Re-enabling shared library breakpoints: 1\n"
> <-
> =shlibs-added,shlib-info=[num="55",name="SKTGraphic.ob",kind="-",dyld-
> addr="0x28a000",reason="dyld",requested-state="?",state="N",path="/
> Developer/Examples/AppKit/Sketch/build/Sketch.build/Sketch
> (Upgraded).build/Objects-normal/ppc/
> SKTGraphic.ob",slide="",addr="",prefix=""]
>
>
> In our case, this message is emitted by one of our arch-specific files,
> macosx/macosx-nat-dyld.c, in a function called macosx_solib_add().

Good idea, unfortunately we're mostly using the generic svr4 stuff.  I
probably COULD do it in our backend but the problem is that this is not QNX
specific.  It needs to be a standard part of GDB because the Eclipse CDT is
going to rely on it.

> 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.

I read that thread.  Very interesting.  This is one of those cases where it
would be nice to have the functionality in gdb but the IDE should be able to
do it easier as long as it has notification.  It should be fairly easy to
get notification from gdb but it doesn't look like Daniel wants people to
rely on stop-on-solib-events so he won't let me mi-ificate it.

cheers,

Kris

Re: [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