RE: [4/4] RFC: implement catch load and catch unload

[Marc Khouzam <marc.khouzam@ericsson.com>]

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com] 
> Sent: Tuesday, January 24, 2012 11:56 AM
> To: Pedro Alves
> Cc: gdb-patches@sourceware.org; Marc Khouzam
> Subject: Re: [4/4] RFC: implement catch load and catch unload
> 
> CC'ing Marc Khouzam for this one sub-thread.
> 
> Pedro> I know Eclipse used to rely "set stop-on-solib-events 
> 1".  Not sure they
> Pedro> still do.  So if it doesn't convert to the MI events, 
> it'll break.  Maybe
> Pedro> just one more reason to make sure they do adjust.  :-)
> 
> I think the change here occurred with the patch to PR 8444.  
> That patch
> changed a printf_filtered to ui_out_text.  I can add the 
> printf_filtered
> back -- but I think it would be better for Eclipse and other 
> MI clients
> to just start examining the new *stopped reasons.  (The MI docs have a
> list of these...)
> 
> Marc, I am curious to know what Eclipse uses this for.

The default GDB integration (DSF) does not use it.  In fact, we
don't offer that feature to our users (but we should).

However, the legacy GDB integration (CDI) does use it:
[1,327,424,864,825] 8-gdb-set stop-on-solib-events 1
[1,327,424,864,826] 8^done

Not having this command won't prevent CDI from debugging,
but will have two impacts, as far as I know:
1- no more user feature to stop on lib events
2- breakpoints set on non-loaded libs will no longer be
installed (since CDI does not use pending breakpoints, but
tries to plant failed bps at each new lib load event)

We do tell people that CDI is not being maintained.
I guess eventually, we have to expect some degradation
as GDB keeps evolving.

Thanks for keeping me in the loop.  Once you decide how
you want GDB to move forward, if needed, I'll open a bug
on CDI to track the breakage.

Thanks

Marc