This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need help figuring out DLL load problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]