PE-COFF and import tables

[Dave Korn]

Vincent R. wrote:
> Hi,
> 
> I already ask a question about PE-COFF and import tables but I got no
> answers.
> So I am trying again.

  Sorry, I must have dropped that one on the floor.

> When using arm-mingw32ce compiler (part of cegcc project),I have noticed
> that some generated dll have a weird import table.
> For instance when looking at the dll libeet-1.dll (from efl project):
> 
> 
>> arm-mingw32ce-objdump -x libeet-1.dll | less
> 
> 0001a050       0001a12c 00000000 00000000 0001a94c 0001a298
> 
>         DLL Name: COREDLL
>         vma:  Hint/Ord Member-Name Bound-To
>         1a5ac       4  _fileno
>         1a5b6      19  _strdup
> 
>  0001a064       0001a138 00000000 00000000 0001aa18 0001a2a4
> 
>         DLL Name: COREDLL
>         vma:  Hint/Ord Member-Name Bound-To
>         1a5c0     174  CreateFileW
>         1a5ce     240  DeleteCriticalSection
>         1a5e6     243  DeleteFileW
>         ...
>         1a782    1322  _strdup
> 
> 
> I can notice that COREDLL file is referenced twice, first one with only 
> two functions
> in it (_fileno, _strdup) and second one with other functions.
> 
> 
> What I would like to understand is how that kind of thing can happen ? 
> Is it a binutils issue or does it have something to do with libtool ?

  This is a bit unusual, we would have to see the linker command line that
builds the DLL to know exactly why this happens.

> In my opinion that kind of things shouldn't happen because _strdup
> is referenced twice and in this case how PE loader is supposed to handle
> this ?

  This is not a problem for the loader.  It doesn't have to decide which of
the import stubs any given call to strdup uses, that is already resolved; it
simply has to insert the run-time address of strdup into both the IATs at the
appropriate place.

  Also it is quite conventional to have multiple import tables for the DLL,
and this is how auto-import works: it scatters many synthetic "import tables"
through the code, each of which has only one single entry that is located, as
if by coincidence, in the opcode field of an instruction that has a reference
to the imported symbol.

> Could it be due to the fact that compiler/linker/libtool see this 2
> functions
> with one type in a module and with another type instead another one ? 

  Dunno.  We need to see the linker command line and look into the objects and
libs that got linked into the DLL to find out.

> Another related remarks is the fact that when exporting some variables from
> a DLL, I can see
> the same kind of issues/differences compared to native tools.

  You can't mean that literally; there is only ever one export table, it's not
possible to have more than one!  Please explain more what happens with exports.

> Finally when testing with older binutils/cegcc, results were a bit
> different because if I
> go back to the first problem instead of having twince the same DLL
> (COREDLL) I had :
> 
> The Import Tables (interpreted .idata section contents)
>  vma:            Hint    Time      Forward  DLL       First
>                  Table   Stamp     Chain    Name      Thunk
>  00016000       000160a4 00000000 00000000 0001679c 000161fc
> 
>         DLL Name: coredll.dll
>         vma:  Hint/Ord Member-Name Bound-To
>         16350       4  _fileno
>         1635a      20  _strdup
> 
>  00016014       000160b4 00000000 00000000 0001684c 0001620c
> 
>         DLL Name: COREDLL
>         vma:  Hint/Ord Member-Name Bound-To
> 
> 
> So during these days there was a slight differences in naming and that
> could explain why
> it was working even if it was already generating a wrong format.

  Is it not working now?  You didn't yet say.  As far as I know, the .DLL
extension should be present in both cases.  I fixed a problem relating to this
just recently:

http://sourceware.org/ml/binutils/2009-03/msg00282.html

... are you using binutils from before or after 1st April (when the patch got
applied)?

    cheers,
      DaveK