This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Need help figuring out DLL load problem
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: danny dot backx at scarlet dot be
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, binutils at sourceware dot org
- Date: Tue, 04 Aug 2009 22:55:34 +0100
- Subject: Re: Need help figuring out DLL load problem
- References: <1248970879.5537.415.camel@pavilion> <4A71DFC8.6060908@gmail.com> <1248976791.5537.420.camel@pavilion> <4A71FAF5.5000908@gmail.com> <1249215774.5537.438.camel@pavilion>
Danny Backx wrote:
> What confuses me is that the ld output files appear to indicate
> different input, see the first couple of lines in the output (before
> gld_arm_wince_pe_after_open and gld_i386pe_after_open).
>
> This appears to indicate different input symbol lists. The difference
> contains one of the symbols we're chasing : __ZNSt8ios_base4InitC1Ev .
>
> Is this meaningful, or is another part of the output key to the answer ?
Well, it's at the root of why pe_find_data_imports thinks it's dealing with a
data export. LD is processing the list of undefined symbols. Any that it finds
are undefined, and for which there is an __imp_* equivalent, it assumes are data
imports that need a fixup. This is the case for __ZNSt8ios_base4InitC1Ev, which
is undefined, but __imp___ZNSt8ios_base4InitC1Ev is defined, so it gets a fixup
applied.
It should not be the case that __ZNSt8ios_base4InitC1Ev is undefined in the
first place, because there should be a jump stub by that name in
libstdc++.dll.a, which jumps through the __imp__ version. (This is why it's
reasonable to infer that if the symbols is still undefined, it must be a data
symbol; function exports all have the jump stub, under the non-prefixed names of
their imports, and so should have been resolved; data items don't have jump
stubs, so anything still unresolved must be a data item.)
So, next question: what's in your libstdc++.dll.a that relates to
__ZNSt8ios_base4InitC1Ev? Here's an example from my cygwin install of tracking
it down:
> $ nm /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a | \
> grep -C6 __ZNSt8ios_base4InitC1Ev
> d001743.o:
> 00000000 i .idata$4
> 00000000 i .idata$5
> 00000000 i .idata$6
> 00000000 i .idata$7
> 00000000 t .text
> 00000000 T __ZNSt8ios_base4InitC1Ev
> U __head_cygstdc___6_dll
> 00000000 I __imp___ZNSt8ios_base4InitC1Ev
>
> d001742.o:
> 00000000 i .idata$4
> 00000000 i .idata$5
> 00000000 i .idata$6
> 00000000 i .idata$7
>
> $ ar x /usr/lib/gcc/i686-pc-cygwin/4.3.2/libstdc++.dll.a d001743.o
> $ objdump -dr d001743.o
>
> d001743.o: file format pe-i386
>
>
> Disassembly of section .text:
>
> 00000000 <__ZNSt8ios_base4InitC1Ev>:
> 0: ff 25 00 00 00 00 jmp *0x0
> 2: dir32 .idata$5
> 6: 90 nop
> 7: 90 nop
What do you get when you try the equivalent on your misbehaving version?
cheers,
DaveK