stop-on-solib-events and Cygwin (or MinGW)

[Gordon Prieur]

Daniel Jacobowitz wrote:
> On Thu, Feb 14, 2008 at 09:01:44AM -0800, Gordon Prieur wrote:
>   
>> Hi,
>>
>>    I've just added support to the NetBeans gdb module for breakpoints
>> set in shared libraries explicity dlopened (as apposed to shared libraries
>> linked at link time). I'm using stop-on-solib-events to do this, and it  
>> works
>> fine on both Solaris and Linux.
>>     
>
> Why do you need to do this?  i.e. what are you doing with breakpoints
> that current versions of GDB don't handle for you?  (There may be a
> good reason, I'm just curious what it is.)
>   

Its customer driven. In NetBeans, breakpoints persist outside of a gdb 
session.
The simplified scenario I'm using in my test cases contains 2 files, 
main.c and
shared.c (shared.c builds into a dll). If I link main.c with the shared 
library then
when I start debugging main, all breakpoints in shared.c are active.

If I don't link the dll into main but explicitly dlopen it, the 
breakpoints aren't
active unless I set them after the dlopen.


>>    However, if I set this property on Windows I don't get stopped after
>> my dlopen/dlclose calls. Is there any way (on Windows) to make this
>> feature work? The alternative is to provide a complete 2nd implementation
>> for Windows (based on stopping in dlopen, calling "finish", and comparing
>> info share from before and after). Since stack information isn't always
>> reliable on Windows, I'm concerned this method won't be very reliable.
>>
>>    Are there technical reasons why stop-on-solib-events doesn't work on
>> Windows? Or is it just unimplemented on that platform? Would I see the
>> same behavior on Vista?
>>     
>
> It's just unimplemented.  However, you might want to try a current CVS
> snapshot.  I think it should work now that Pedro switched win32 over
> to XML-based libraries.
>   

Will this be part of gbd 6.8? From my point of view, its only fixed when 
I can
recommend a specific version of Cygwin and/or MinGW to my customers. Even
then, I'll need to support legacy versions without this feature. So even 
if its
fixed, I think I'll need to maintain my alternate Windows implementation for
a while.

Thanks,
Gordon