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

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.

    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?

Thanks,
Gordon

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

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

-- 
Daniel Jacobowitz
CodeSourcery

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

On Thu, Feb 14, 2008 at 09:41:15AM -0800, Gordon Prieur
wrote:
> 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.

That sounds like a bug in GDB.  We need a test case. 
Actually, it
sounds like win32/2369.  Anyway, there is no reason this
should not
work from GDB without your having to do anything special.

> Will this be part of gbd 6.8?

Yes.

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

If you don't want to ship your own GDB, or require a new
release,
then we can't help you with GDB bugs - if you find a time
machine
sitting around somewhere, do let me know 

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz wrote:
> On Thu, Feb 14, 2008 at 09:41:15AM -0800, Gordon Prieur
wrote:
>   
>> 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.
>>     
>
> That sounds like a bug in GDB.  We need a test case. 
Actually, it
> sounds like win32/2369.  Anyway, there is no reason
this should not
> work from GDB without your having to do anything
special.
>   

Its similar to 2369 but there are several differences. First
off, I'm 
running  in mi mode
and I don't really expect it to handle breakpoints in
unloaded dlls. In 
command line, it
asks if it should be left "pending on future shared
library load".

But I also tried it from the command line (w/o mi) and it
still failed. 
But that scenario
isn't identical to the one in 2369. In 2369, gdb tells you
the bp fails 
to get set. In my
case (using Cygwin gdb 6.5.50)  I get a message
"Pending breakpoint 
"shared.c:5"
resolved" but it gets ignored. I reran with a
breakpoint in my main 
program (before
the call to the bp in my dll) and both worked.

I've attached my sources. Since I built from NetBeans
projects I'm not 
including any
Makefiles. Build shared.c into a dll and reference it from
app.c. Since 
I didn't want
to muck with dlopen finding the dll, I hardcoded the path in
app.c. 
You'll need to
change it to point to the location you put libshared.dll.


>> Will this be part of gbd 6.8?
>>     
>
> Yes.
>
>   
>> 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.
>>     
>
> If you don't want to ship your own GDB, or require a
new release,
> then we can't help you with GDB bugs - if you find a
time machine
> sitting around somewhere, do let me know 
>   

We're considering bundling compilers, gdb, and make with
NetBeans. In 
the mean time,
I have a time machine called patience

Incidentally, my alternate Windows implementation seems to
work. I set a 
bp in dlopen,
call "finish", and reset all failed NetBeans
breakpoints . Note that 
"NetBeans breakpoints"
are different than gdb breakpoints. When I start gdb I
attempt to create 
a gdb breakpoint
for each NetBeans breakpoint. The failed ones are the ones
I'll retry 
after the dlopen. In
most cases, the failure is because the bp is in code not
compiled into 
the app.

Gordon

On Thu, Feb 14, 2008 at 10:58:02AM -0800, Gordon Prieur
wrote:
> Its similar to 2369 but there are several differences.
First off, I'm  
> running  in mi mode
> and I don't really expect it to handle breakpoints in
unloaded dlls. In  
> command line, it
> asks if it should be left "pending on future
shared library load".

Vladimir added support for this to GDB/MI on 2007-12-14.

Vladimir, I noticed there's no NEWS entry for this.  If you
agree
there should be, could you add one?

> I've attached my sources. Since I built from NetBeans
projects I'm not  
> including any
> Makefiles. Build shared.c into a dll and reference it
from app.c. Since I 
> didn't want
> to muck with dlopen finding the dll, I hardcoded the
path in app.c.  
> You'll need to
> change it to point to the location you put
libshared.dll.

Thanks for the testcase.  I hope someone has time to fix
this.

-- 
Daniel Jacobowitz
CodeSourcery

> From:  Vladimir Prus <ghostcs.msu.su>
> Date:  Thu, 14 Feb 2008 22:18:03 +0300
> Cc: gdb-patchessources.redhat.com
> 
> > Vladimir, I noticed there's no NEWS entry for
this.  If you agree
> > there should be, could you add one?
> 
> What about the below?

Fine with me, thanks.