* arm-wince-pe, dll auto-importing broken when
@ 2006-05-05 1:49 Pedro Alves
2006-05-05 2:03 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2006-05-05 1:49 UTC (permalink / raw)
To: binutils
Hi all,
Linking against two import libs:
dll 1: import lib generated by MSFT's evc (I think version 4)
dll 2: import lib generated by ld.
Triggers a bug that make auto-imported vars misbehave.
I can see at runtime that the loader isn't processing dll auto-imports
from dll 2 correctly.
It is the presence of dll 1 that triggers the bug. Note that this bug
never shows up if only implibs generated by ld are used.
Ex:
int __argc is autoimported from dll 2. (cegcc.dll)
At runtime, I get &__argc == 0x000150a8
Which corresponds to:
SORT(*)(.idata$5)
.idata$5 0x000150a4 0x4
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/libcegcc.dll.a(d000000.o)
.idata$5 0x000150a8 0x4
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/libcegcc.dll.a(d000203.o)
0x000150a8 __imp___argc
0x000150a8 __imp___argc
So, the fixups didn't end up resolved correctly. Probably the loader
fixed up the wrong address.
I think the problem is related to the fact that the import lib for dll 1
exports __NULL_IMPORT_DESCRIPTOR,
and that ends up in the final executable along the .idata$3 import
descriptor terminator generated by ld.
Here is a snippet of the map file:
.idata$2 0x00015028 0x14
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.a)
0x00015028 __IMPORT_DESCRIPTOR_zlibce
SORT(*)(.idata$3)
.idata$3 0x0001503c 0x14
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c)
0x0001503c __NULL_IMPORT_DESCRIPTOR
0x00015050 0x4 LONG 0x0
0x00015054 0x4 LONG 0x0
0x00015058 0x4 LONG 0x0
0x0001505c 0x4 LONG 0x0
0x00015060 0x4 LONG 0x0
If I override __NULL_IMPORT_DESCRIPTOR, by adding a global var:
int __NULL_IMPORT_DESCRIPTOR;
the problem goes away, as ld discards __NULL_IMPORT_DESCRIPTOR from the
implib.
The map file looks like this then:
(...)
.idata$2 0x00015028 0x14
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.a)
0x00015028 __IMPORT_DESCRIPTOR_zlibce
SORT(*)(.idata$3)
0x0001503c 0x4 LONG 0x0
0x00015040 0x4 LONG 0x0
0x00015044 0x4 LONG 0x0
0x00015048 0x4 LONG 0x0
0x0001504c 0x4 LONG 0x0
And at runtime &__argc has the correct address.
Am I right that there should only by 0x14 bytes in idata$3? If yes,
where should I look to fix it? Else, any hints on where the problem may be?
Cheers,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 1:49 arm-wince-pe, dll auto-importing broken when Pedro Alves
@ 2006-05-05 2:03 ` Pedro Alves
2006-05-05 2:17 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2006-05-05 2:03 UTC (permalink / raw)
To: binutils
I have to reply to myself, but I just noticed what probably the real
problem is. I was close, but not there.
SORT(*)(.idata$3)
.idata$3 0x0001503c 0x14
/usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c)
0x0001503c __NULL_IMPORT_DESCRIPTOR
.idata$3 0x00015050 0x14 fu000001.o
0x00015064 0x4 LONG 0x0
0x00015068 0x4 LONG 0x0
0x0001506c 0x4 LONG 0x0
0x00015070 0x4 LONG 0x0
0x00015074 0x4 LONG 0x0
The os loader will see __NULL_IMPORT_DESCRIPTOR, which is an import
descriptor terminator, and will not process the fu000001.o
import descriptor.
So I guess I should be looking at why isn't __NULL_IMPORT_DESCRIPTOR
discarded by default.
Any hints?
Cheers,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 2:03 ` Pedro Alves
@ 2006-05-05 2:17 ` Daniel Jacobowitz
2006-05-05 2:35 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2006-05-05 2:17 UTC (permalink / raw)
To: Pedro Alves; +Cc: binutils
On Fri, May 05, 2006 at 03:03:15AM +0100, Pedro Alves wrote:
> I have to reply to myself, but I just noticed what probably the real
> problem is. I was close, but not there.
>
> SORT(*)(.idata$3)
> .idata$3 0x0001503c 0x14
> /usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c)
> 0x0001503c __NULL_IMPORT_DESCRIPTOR
> .idata$3 0x00015050 0x14 fu000001.o
> 0x00015064 0x4 LONG 0x0
> 0x00015068 0x4 LONG 0x0
> 0x0001506c 0x4 LONG 0x0
> 0x00015070 0x4 LONG 0x0
> 0x00015074 0x4 LONG 0x0
>
> The os loader will see __NULL_IMPORT_DESCRIPTOR, which is an import
> descriptor terminator, and will not process the fu000001.o
> import descriptor.
> So I guess I should be looking at why isn't __NULL_IMPORT_DESCRIPTOR
> discarded by default.
> Any hints?
Now, I don't know the first thing about PE, so I'm guessing. But
what's in fu00001.o that you want to get processed? The comments in
dlltool say .idata$3 are just supposed to be terminators.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 2:17 ` Daniel Jacobowitz
@ 2006-05-05 2:35 ` Pedro Alves
2006-05-05 2:50 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2006-05-05 2:35 UTC (permalink / raw)
To: binutils
Daniel Jacobowitz wrote:
> On Fri, May 05, 2006 at 03:03:15AM +0100, Pedro Alves wrote:
>
>> I have to reply to myself, but I just noticed what probably the real
>> problem is. I was close, but not there.
>>
>> SORT(*)(.idata$3)
>> .idata$3 0x0001503c 0x14
>> /usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c)
>> 0x0001503c __NULL_IMPORT_DESCRIPTOR
>> .idata$3 0x00015050 0x14 fu000001.o
>> 0x00015064 0x4 LONG 0x0
>> 0x00015068 0x4 LONG 0x0
>> 0x0001506c 0x4 LONG 0x0
>> 0x00015070 0x4 LONG 0x0
>> 0x00015074 0x4 LONG 0x0
>>
>> The os loader will see __NULL_IMPORT_DESCRIPTOR, which is an import
>> descriptor terminator, and will not process the fu000001.o
>> import descriptor.
>> So I guess I should be looking at why isn't __NULL_IMPORT_DESCRIPTOR
>> discarded by default.
>> Any hints?
>>
>
> Now, I don't know the first thing about PE, so I'm guessing. But
> what's in fu00001.o that you want to get processed? The comments in
> dlltool say .idata$3 are just supposed to be terminators.
>
>
It is related to auto importing. It contains the auto import fixup
entries. It consists of an entry of type IMAGE_IMPORT_DESCRIPTOR which takes
0x14 bytes.
See comments at the top of pe-dll.c, and also make_import_fixup_entry in
that same file for where it is generated.
The loader will process the the null terminated array of import
descriptors. Since __NULL_IMPORT_DESCRIPTOR is filled with 0,
the loader will stop processing there instead of at that,
0x00015064 0x4 LONG 0x0
0x00015068 0x4 LONG 0x0
0x0001506c 0x4 LONG 0x0
0x00015070 0x4 LONG 0x0
0x00015074 0x4 LONG 0x0
Which is really the same as an unnamed __NULL_IMPORT_DESCRIPTOR.
Cheers,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 2:35 ` Pedro Alves
@ 2006-05-05 2:50 ` Pedro Alves
2006-05-05 13:14 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2006-05-05 2:50 UTC (permalink / raw)
To: binutils
Pedro Alves wrote:
> Daniel Jacobowitz wrote:
>> On Fri, May 05, 2006 at 03:03:15AM +0100, Pedro Alves wrote:
>>
>>> I have to reply to myself, but I just noticed what probably the real
>>> problem is. I was close, but not there.
>>>
>>> SORT(*)(.idata$3)
>>> .idata$3 0x0001503c 0x14
>>> /usr/local/lib/gcc/arm-wince-pe/4.1.1/../../../../arm-wince-pe/lib/zlibce.lib(zlibce.dll.c)
>>>
>>> 0x0001503c __NULL_IMPORT_DESCRIPTOR
>>> .idata$3 0x00015050 0x14 fu000001.o
>>> 0x00015064 0x4 LONG 0x0
>>> 0x00015068 0x4 LONG 0x0
>>> 0x0001506c 0x4 LONG 0x0
>>> 0x00015070 0x4 LONG 0x0
>>> 0x00015074 0x4 LONG 0x0
>>>
>>> The os loader will see __NULL_IMPORT_DESCRIPTOR, which is an import
>>> descriptor terminator, and will not process the fu000001.o
>>> import descriptor.
>>> So I guess I should be looking at why isn't __NULL_IMPORT_DESCRIPTOR
>>> discarded by default.
>>> Any hints?
>>>
>>
>> Now, I don't know the first thing about PE, so I'm guessing. But
>> what's in fu00001.o that you want to get processed? The comments in
>> dlltool say .idata$3 are just supposed to be terminators.
>>
>>
> It is related to auto importing. It contains the auto import fixup
> entries. It consists of an entry of type IMAGE_IMPORT_DESCRIPTOR which
> takes
> 0x14 bytes.
> See comments at the top of pe-dll.c, and also make_import_fixup_entry
> in that same file for where it is generated.
>
> The loader will process the the null terminated array of import
> descriptors. Since __NULL_IMPORT_DESCRIPTOR is filled with 0,
> the loader will stop processing there instead of at that,
>
> 0x00015064 0x4 LONG 0x0
> 0x00015068 0x4 LONG 0x0
> 0x0001506c 0x4 LONG 0x0
> 0x00015070 0x4 LONG 0x0
> 0x00015074 0x4 LONG 0x0
> Which is really the same as an unnamed __NULL_IMPORT_DESCRIPTOR.
>
Actually, shouldn't auto import fixup entries be stored in .idata$2
instead of .idata$3 subsection?
Cheers,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 2:50 ` Pedro Alves
@ 2006-05-05 13:14 ` Daniel Jacobowitz
2006-05-05 16:49 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2006-05-05 13:14 UTC (permalink / raw)
To: binutils
On Fri, May 05, 2006 at 03:49:39AM +0100, Pedro Alves wrote:
> Actually, shouldn't auto import fixup entries be stored in .idata$2
> instead of .idata$3 subsection?
It surely looks that way to me, but ask someone who has used this
stuff...
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: arm-wince-pe, dll auto-importing broken when
2006-05-05 13:14 ` Daniel Jacobowitz
@ 2006-05-05 16:49 ` Pedro Alves
0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2006-05-05 16:49 UTC (permalink / raw)
To: binutils
Daniel Jacobowitz wrote:
>On Fri, May 05, 2006 at 03:49:39AM +0100, Pedro Alves wrote:
>
>
>>Actually, shouldn't auto import fixup entries be stored in .idata$2
>>instead of .idata$3 subsection?
>>
>>
>
>It surely looks that way to me, but ask someone who has used this
>stuff...
>
>
>
Only had time for a quick test, so I changed .idata$3 to .data$2 in
make_import_fixup_entry,
relinked the dll 2 import lib, relinked the test app, and shure enough,
it works.
I will send a patch later if nobody shouts.
Cheers,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-05-05 13:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-05 1:49 arm-wince-pe, dll auto-importing broken when Pedro Alves
2006-05-05 2:03 ` Pedro Alves
2006-05-05 2:17 ` Daniel Jacobowitz
2006-05-05 2:35 ` Pedro Alves
2006-05-05 2:50 ` Pedro Alves
2006-05-05 13:14 ` Daniel Jacobowitz
2006-05-05 16:49 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).