Re: [fpc-devel] internal linker import by index patch (xbox)
From: Andrew Haines [EMAIL PROTECTED] Hi, This patch is not ready yet, but can anyone give comments on the correctness of the third hunk in the patch dealing with AOrdNr? I've been working on getting fpc able to make xbox(1) programs and on the xbox there are no libraries but only kernel imports which are imported by number. A short explanation: An xbox exe is very similar to a win32 exe. It only links to the xbox kernel and imports functions by index. If an exe is generated that doesn't link to the standard win32 libs like kernel32.dll, then the program can be converted to an xbe(xbox executable) using a program called cxbe. So... with the third hunk applied and a bare system unit and a bunch of small changes here and there, I've been able to make a xbox program with fpc that I converted with cxbe. (all it does is write to video memory and then reboot) Is the patch correct? I suspect that importing by ordinal is not currently working for regular exe's made with the internal linker. 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. The patch changes so that the Import address table is putting $8000 or'ed against the import number instead of an RVA pointing to the import number(which is incorrect since a RVA is used here only if it is an import by name) Sorry if none of this makes sense, I think I may have overloaded my brain on this one :) Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] internal linker import by index patch (xbox)
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 $8000 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. thanks for your patience, Andrew ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] internal linker import by index patch (xbox)
From: Andrew Haines [EMAIL PROTECTED] 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 $8000 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? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] internal linker import by index patch (xbox)
Yury Sidorov wrote: From: Andrew Haines [EMAIL PROTECTED] 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 $8000 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
