This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
PE-COFF and import tables
- From: "Vincent R." <forumer at smartmobili dot com>
- To: <binutils at sourceware dot org>, Kai Tietz <ktietz70 at googlemail dot com>, <dave dot korn dot cygwin at googlemail dot com>, Vincent Torri <vtorri at univ-evry dot fr>
- Date: Sat, 09 May 2009 11:27:37 +0200
- Subject: PE-COFF and import tables
Hi,
I already ask a question about PE-COFF and import tables but I got no
answers.
So I am trying again.
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 ?
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 ?
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 ?
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.
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.
If a PE-COFF expert could give his opinion, it would help me a lot.