arm-wince-pe, dll auto-importing broken when

arm-wince-pe, dll auto-importing broken when

[Pedro Alves]

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

Re: arm-wince-pe, dll auto-importing broken when

[Pedro Alves]

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

Re: arm-wince-pe, dll auto-importing broken when

[Daniel Jacobowitz]

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

Re: arm-wince-pe, dll auto-importing broken when

[Pedro Alves]

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

Re: arm-wince-pe, dll auto-importing broken when

[Pedro Alves]

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

Re: arm-wince-pe, dll auto-importing broken when

[Daniel Jacobowitz]

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

Re: arm-wince-pe, dll auto-importing broken when

[Pedro Alves]

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