Re: [Mingw-users] gcc/g++ (v3.2) -shared && gdb (RC)

[Luke D. <cod...@ho...>]

----- Original Message -----
From: "Paul G." <pga...@at...>
To: <min...@li...>
Sent: Wednesday, January 29, 2003 9:12 AM
Subject: [Mingw-users] gcc/g++ (v3.2) -shared && gdb (RC)


> Hi folks,
>
> Not exactly sure where to begin with this sort of question.
>
> I have noticed some difficulties when I have attempted to load .dll debug
data for
> dynamic access by Mingw gdb (via implementation/use of "gcc -shared").
>
> This problem does not appear if I use "dllwrap".  "gcc -shared", at least
I would think so,
> should be capable of generating all of the necessary symbols, whether
those symbols
> include debug data or not.

I don't see how there could be a difference between using dllwrap and
gcc -shared, unless something else is different (e.g. using an import
library vs. linking directly to the DLL).

>
> The actual problem has to do with gdb (Release Candidate or RC) not
dynamically
> loading all of the .dll debug symbols that are particular application is
requesting.
>
> The build itself actually creates debug data and integrates that .dll
data, in some form,
> via the use of "gcc -g3 -shared".  "gdb" (RC) does not seem to be
consistently loading all of
> the .dll debug data.

Firstly, why do you talk about "-g3"? Does it behave any different than
"-g"?

>
> If this is a known bug, please let me know.  What I know of the so-called
"bug" is mostly
> based on "rumor".  However, these rumors are becoming more persistent as
of late.
>
> Is anyone working on this or are there any plans that any of the
developers have in
> regards to this?
>
> Is it not possible to generate .dll debug data which is useable and
loadable by gdb RC
> through the use of "gcc -g/3 -shared"?
>
> Thanks,
>
> Paul G.

I just tried compiling a simple test case using "gcc -shared" and linking
directly to the DLL and I did find one problem. The example .exe is:

int foo(int a);

int main(void)
{
        int x = 3;
        int y = foo(x);

        return y + 1;
}

The example .dll is:

int foo(int a)
{
        int b = a + 5;

        return b * 2;
}

If I use GDB and try to step into the call to foo(), it doesn't work and
just steps over it to the "return". I think the problem is that "foo" is
just a stub that jumps indirectly using the import table (i.e. __imp__foo).
However, if I use the GDB command "stepi" a few times I can step first into
the stub:

0x402af0 <foo>: jmp    *0x406158

Then using "stepi" again steps into the foo() function in the DLL, and GDB
correctly loads the DLL symbols because I can step through foo(), etc. On
the other hand, using "b foo" correctly sets a breakpoint in the DLL instead
of in the stub, so apparently GDB knows that it is a stub in this case. I
don't know if this is a bug or not. If the program is modified to declare
foo() as dllimport, this problem does not occur because the compiler knows
to call *__imp_foo instead of the stub. Of course, this may have nothing to
do with your problem, so if that is true then can you provide a minimal test
case that demonstrates the problem?

Luke