[fpc-devel] internal linker import by index patch (xbox)

[Andrew Haines]

Yury Sidorov wrote:
> From: "Andrew Haines" <AndrewD207 at aol.com>
>> Yury Sidorov wrote:
>>>
>>> Actually import by ordinal is implemented in works. Look at line 2416 of
>>> ogcoff.pas
>>> When AOrdNr < 0 it indicates that import is by name, but ordinal number
>>> is specified as hint. Whan AOrdNr > 0 then import by ordinal only.
>>>
>>
>> Okay yes I see that, but that is for the import lookup table not the
>> import address table, the import address table is the same format as the
>> import lookup table.
>>
>> Here is the behavior I observed:
>>
>> I import a function by index
>>
>> function SomeFunction: stdcall; external 'xboxkrnl.exe' index '1';
>>
>> when it is compiled the start of the .idata section looks like this:
>>
>> ImportLookupTablePtr
>> DateTimeStamp
>> Junk
>> PtrToLibName
>> ImportAddressTablePtr
>>
>> The Import Lookup Table is written correctly with the ordinal name as
>> expected. When I look at the Import Address Table, the entries are *not
>> the same* as the lookup table, as they should be, but instead *point* to
>> an address that contains the ordinal(not or'ed), when it should contain
>> $80000000 or'ed against the import ordinal.
>>
>>
>>> From the MS docs talking about the Import Address Table:
>>
>> "Import Address Table RVA(Thunk Table): The RVA of the import address
>> table. The contents of this table are identical to the contents of the
>> lookup table until the image is bound."
>>
>> So even if my confusing explanation doesn't make sense, the Address
>> Table should mirror the Lookup Table which it doesn't.
>>
>> It looks like maybe you are writing a Hint/Name table entry for an
>> ordinal which is only done when importing by name.
> 
> Yes. You are right. Import Address Table should contain the same data as
> Import Lookup Table. Currently it contains different data when importing
> by ordinal.
> It should be fixed, but it currently this bug has no effect on
> win32/64/CE. EXEs with ordinal imports are loaded properly.
> Does it afeect xbox?
> 

Yes. The xbox exe loader does not know it is looking at a IAT in the
.idata section, but thinks it is looking at a different IAT not in the
idata (which neither gcc nor fpc create, only the MS compiler seems to
make it) section which does not have a corresponding Lookup table. I
suspect the windows exe loader is checking the Lookup Table when it
finds invalid data in the IAT.


Andrew