gdb and Dll

gdb and Dll

[Heiko Gerdau]

Hi,

i found quit a few questions about debugging relocatable dlls on
Windows, but no answers. Does that mean you can not debug dlls with gdb?

I found the gdb command "dll-symbols" which seems to be made for this
purpose. But at least for me, using the mingw version of gdb 5.2.1, it
seems to have no effects. Is there anybody on this list who could give
me a hint or confirmation that is it not possible to debug dlls with
gdb.

Thanks for any help

Greetings
Heiko  

Re: gdb and Dll

[Joel Brobecker]

> i found quit a few questions about debugging relocatable dlls on
> Windows, but no answers. Does that mean you can not debug dlls with gdb?
> 
> I found the gdb command "dll-symbols" which seems to be made for this
> purpose. But at least for me, using the mingw version of gdb 5.2.1, it
> seems to have no effects. Is there anybody on this list who could give
> me a hint or confirmation that is it not possible to debug dlls with
> gdb.

I would recommend having a look at the GDB PR database. I believe ACT
opened a couple of PRs and suggested some fixes that seemed to be
working for us, but I wasn't involved in this so I can't say more.
There was also a recent patch posted by Chris Faylor I think, which also
fixed quite a number of problems with DLLs on Windows.

-- 
Joel

Re: gdb and Dll

[Christopher Faylor]

On Wed, Nov 27, 2002 at 10:13:28AM +0100, Heiko Gerdau wrote:
>Hi,
>
>i found quit a few questions about debugging relocatable dlls on
>Windows, but no answers. Does that mean you can not debug dlls with gdb?

I debug dlls all of the time.

>I found the gdb command "dll-symbols" which seems to be made for this
>purpose. But at least for me, using the mingw version of gdb 5.2.1, it
>seems to have no effects. Is there anybody on this list who could give
>me a hint or confirmation that is it not possible to debug dlls with
>gdb.

AFAIK, the "mingw version" is a modified, unsupported version of gdb.
Certainly simple debugging of dlls with the cygwin version of gdb work
ok, especially in the current cvs revision or, presumably, in the
upcoming gdb 5.3.

There is one long-standing "gotcha" in debugging dlls however.  Currently
you can only set breakpoints on line numbers not on symbol names if the
dll is not loaded.  That is you can't do:

  dll-symbols foo.dll
  bp foo

You have to, instead do:

  dll-symbols foo.dll
  list foo
  bp <first line of foo>

cgf

Re: gdb and Dll

[Andrew Cagney]

> There is one long-standing "gotcha" in debugging dlls however.  Currently
> you can only set breakpoints on line numbers not on symbol names if the
> dll is not loaded.  That is you can't do:
> 
>   dll-symbols foo.dll
>   bp foo
> 
> You have to, instead do:
> 
>   dll-symbols foo.dll
>   list foo
>   bp <first line of foo>

Weird.  Create a bug report.

Andrew

Re: gdb and Dll

[Christopher Faylor]

On Wed, Nov 27, 2002 at 07:57:16PM -0500, Andrew Cagney wrote:
>
>>There is one long-standing "gotcha" in debugging dlls however.  Currently
>>you can only set breakpoints on line numbers not on symbol names if the
>>dll is not loaded.  That is you can't do:
>>
>>  dll-symbols foo.dll
>>  bp foo
>>
>>You have to, instead do:
>>
>>  dll-symbols foo.dll
>>  list foo
>>  bp <first line of foo>
>
>Weird.  Create a bug report.

There already is one, I believe, complete with patch, which I'm testing
now.  I'd give you a URL but my browser is sick right now.  I just did a
search for a topic with dll in it in gnats and found it.  This was after
Joel B.  suggested that a number of PRs had been filed for dll handling.

FWIW, I mentioned this behavior to a couple of gdb engineers two or
three years ago and I was almost given to believe that it was expected
behavior.

cgf

Re: gdb and Dll

[Christopher Faylor]

On Wed, Nov 27, 2002 at 08:11:54PM -0500, Christopher Faylor wrote:
>On Wed, Nov 27, 2002 at 07:57:16PM -0500, Andrew Cagney wrote:
>>
>>>There is one long-standing "gotcha" in debugging dlls however.  Currently
>>>you can only set breakpoints on line numbers not on symbol names if the
>>>dll is not loaded.  That is you can't do:
>>>
>>>  dll-symbols foo.dll
>>>  bp foo
>>>
>>>You have to, instead do:
>>>
>>>  dll-symbols foo.dll
>>>  list foo
>>>  bp <first line of foo>
>>
>>Weird.  Create a bug report.
>
>There already is one, I believe, complete with patch, which I'm testing
>now.  I'd give you a URL but my browser is sick right now.  I just did a
>search for a topic with dll in it in gnats and found it.  This was after
>Joel B.  suggested that a number of PRs had been filed for dll handling.

The GNATS id is 780 and the patch enclosed therein seems to work ok.

cgf

RE: gdb and Dll

[Heiko Gerdau]

> >>>There is one long-standing "gotcha" in debugging dlls 
> however.  Currently
> >>>you can only set breakpoints on line numbers not on symbol 
> names if the
> >>>dll is not loaded.  That is you can't do:
> >>>
> >>>  dll-symbols foo.dll
> >>>  bp foo
> >>>
> >>>You have to, instead do:
> >>>
> >>>  dll-symbols foo.dll
> >>>  list foo
> >>>  bp <first line of foo>

eather case does not work for me. I tried with GNU gdb 2002-07-19-cvs
(cygwin-special) that comes with the cygwin distribution and with
gdb-5.2.1 from mingw.

I'm new to gdb so maybe I miss something else. Here is what I'm doing
(with the cygwin version):

First try:
-----------
gdb -nw myproc.exe
GNU gdb 2002-07-19-cvs (cygwin-special)......

(gdb) directory /cygdrive/d/test
Source directories searched: /cygdrive/d/test:$cdir:$cwd
(gdb) break main
Breakpoint 1 at 0x6314da: file main.cpp, line 133.
(gdb) run
Starting program: /cygdrive/d/test/bin/myproc.exe

Breakpoint 1, main (argc=1, argv=0x37da990) at risk.cpp:133
133	    int lReturn = 0 ;
(gdb) dll-symbols mydll.dll
(gdb) list Data2String
No line number known for Data2String.
(gdb) break subs.cpp:182
Breakpoint 2 at 0x100268cf: file subs.cpp, line 182.
(gdb) c
Continuing.
warning: Cannot insert breakpoint 2:
Cannot access memory at address 0x100268cf
--------------------------------------------------

Second Try:
------------
gdb -nw mydll.dll
GNU gdb 2002-07-19-cvs (cygwin-special)....

(gdb) directory /cygdrive/d/test
Source directories searched: /cygdrive/d/test:$cdir:$cwd
(gdb) list Data2String
176	//
177	//
178
////////////////////////////////////////////////////////////////////////
///////
179	char*
180	Data2String( COLDATATYPE cdt, double dVal, const char* pszVal,
char* pszData, long len )
181	{
182	    if ( NULL == pszData || 0 == len )
183	        return 0 ;
184	
185	    // set the string to empty (will be checked later)
(gdb) break 182
Breakpoint 1 at 0x100268cf: file subs.cpp, line 182.
(gdb) exec-file myproc.exe
(gdb) run
Starting program: /cygdrive/d/test/bin/myproc.exe 
warning: Cannot insert breakpoint 1:
Cannot access memory at address 0x100268cf
-----------------------------------------------------

I also tried to set a breakpoint into DllMain with a different result:
this time gdb did not complain about accessing memory but on the other
hand did not break. 

> The GNATS id is 780 and the patch enclosed therein seems to work ok.

Before I learn how to build it myself, could you send me the gdb.exe
containing those patches so that I can try that version?

Thank you

Greetings
Heiko

Re: gdb and Dll

[Andrew Cagney]

> FWIW, I mentioned this behavior to a couple of gdb engineers two or
> three years ago and I was almost given to believe that it was expected
> behavior.

Wouldn't suprize me :-(

Users always need to keep GDB developers on their toes by constantly 
expanding the bounds of what GDB is expected to do.

Andrew

Re: gdb and Dll

[Christopher Faylor]

On Thu, Nov 28, 2002 at 01:39:57PM +0100, Heiko Gerdau wrote:
>> The GNATS id is 780 and the patch enclosed therein seems to work ok.
>
>Before I learn how to build it myself, could you send me the gdb.exe
>containing those patches so that I can try that version?

Actually, no, I'd rather not get into the business of sending private
binaries.  I see a tech support scenario developing in that situation.
I build binaries for myself.  I don't want to be in a situation of
answering questions about my personal versions of gdb.

Building a new version of gdb is not that hard.  I urge you to try it.

RE: gdb and Dll

[Heiko Gerdau]

> >Before I learn how to build it myself, could you send me the gdb.exe
> >containing those patches so that I can try that version?
> 
> Actually, no, I'd rather not get into the business of sending private
> binaries.  I see a tech support scenario developing in that situation.
> I build binaries for myself.  I don't want to be in a situation of
> answering questions about my personal versions of gdb.

I see your point, sorry for bothering you. It was just meant to test if
it would solve the problems or if there is something else broken in my
configuration on win xp.

> Building a new version of gdb is not that hard.  I urge you to try it.

Ok, I tried to build the insight version exactly as outlined in

http://sources.redhat.com/insight/cygwin.html

I used the gdb_5_2-branch. And configure, make, make install in the
cygwin bash shell.  

There were errors in src/tk/win/rc some of the cursors were broken (for
instance cursor5e.cur). I just copied other cursors of it to continue
compiling.

There were errors in src/gdb/ with the yacc-files p-exp.y, m2-exp.y,
f-exp.y, c-exp.y about missing ";". After inserting them i could build
and install it to cywin/usr/local/. When start any of the executables I
get an error that the application could not be initialized (0xc0000022).

This is sort of frustrating.

I tried the same thing without passing a branch to the cvs co command
with the same results except the errors with *-exp.y did not happen.

What do I miss?

Any help is appreciated, thanks.

Greetings
Heiko