Empty IAT entry

[Craig Edwards]

On Thu, 15 Jul 2004 15:40:03 +0100, Nick Clifton <nickc@redhat.com> wrote:
>    (Sorry for the long delay in replying to your email)

No dramas.  I appreciate the reply...

> For which target ?  Using what command line ?  Can you include the  
> simple C program so that we can reproduce the problem ourselves ?

I am using "gcc (GCC) 3.3.1 (cygming special)" on Windows 2000 with no  
specified target (so I guess that defaults to i686-pc-cygwin).  A simple  
example that repeats the problem is shown below (blah.c).  The command  
line I used to compile the sample program is:   gcc blah.c

--------------------------------
#include <stdio.h>
int main(int argc, char **argv)
{
	printf("hi there");
}
--------------------------------

objdump -x a.exe reports:

<snip>
The Data Directory
Entry 0 00000000 00000000 Export Directory [.edata (or where ever we found  
it)]
Entry 1 00004000 000001ec Import Directory [parts of .idata]
Entry 2 00000000 00000000 Resource Directory [.rsrc]
Entry 3 00000000 00000000 Exception Directory [.pdata]
Entry 4 00000000 00000000 Security Directory
Entry 5 00000000 00000000 Base Relocation Directory [.reloc]
Entry 6 00000000 00000000 Debug Directory
Entry 7 00000000 00000000 Description Directory
Entry 8 00000000 00000000 Special Directory
Entry 9 00000000 00000000 Thread Storage Directory [.tls]
Entry a 00000000 00000000 Load Configuration Directory
Entry b 00000000 00000000 Bound Import Directory
Entry c 00000000 00000000 Import Address Table Directory
Entry d 00000000 00000000 Delay Import Directory
Entry e 00000000 00000000 Reserved
Entry f 00000000 00000000 Reserved

There is an import table in .idata at 0x404000

The Import Tables (interpreted .idata section contents)
  vma:            Hint    Time      Forward  DLL       First
                  Table   Stamp     Chain    Name      Thunk
  00004000	00004040 00000000 00000000 000041c0 00004088
</snip>

There is definitely an import table that contains perfectly valid IAT  
entries, but for some reason the first thunk isn't populated in the Data  
Directory.  Interestingly this example  program compiles and executes just  
perfectly under Windows, so it is may not be a bug.  Presumably the WinXX  
PE loader is smart enough to manually traverse the import table until it  
finds the first thunk.

The reason I stumbled onto this is that I am writing a development kit for  
the XBOX.  The XBOX executes plain old PE files (albeit with a slightly  
modified header).  However, the XBOX PE loader apparently doesn't behave  
the same as its WinXX counterpart, and it expects the value to be  
populated in the header.

In the end, I got around this by post-processing the generated EXE, doing  
the manual traversal myself, and getting the value directly.

--
Craig Edwards