RE: bfd/peigen.c problems and fix

[Szabolcs Szakacsits <szaka at F-Secure dot com>]

On Thu, 11 May 2000, Donn Terry wrote:

> 1) I believe that the DataSize entry for the ImportTable is
> correct: it's the size of the Import Directory Table (the n*0x14 byte
> header), not including the corresponding Import Lookup Table and
> Import Address Table.  Thus a (smallish) value of the form n*0x14
> appears correct (just not intuitive).

Nope, just investigate a few more dll's, e.g. kernel32.dll.
 
> 2) The for loop that dumps the ILT/IAT is checking for datasize, when
> it just should be exiting when finding the terminating zero.  Delete
> the test for datasize in the for statement itself (replacing it with
> nothing) and it should work just right (it does for me).  

Yes it should but who can be sure when dealing with Microsoft files?
Personally I just feel better if I know we remain within the section.
Or they could overlap? I don't think so ... [at least at present].

> (That's why taking datasize
> from the .idata section size worked better than taking it from the
> DataDirectory, 

No, it worked worse since sometimes it took the size [and the import table
address] from the wrong place and truncated the import section or just
coredumped.

> and why now, when taking it from the DataDirectory, it
> truncates all .import sections.)

No, now the size is the section size and stops when it finds no more data
[or end of the section].

> 3) A silent change (maybe intended, maybe not) was made.  The size of the
> *EXport* table is printed twice, as below.
>   Number in:
>         Export Address Table            000002a9
>         [Name Pointer/Ordinal] Table    000002a9
> 
> Prior to this, it was printed without leading zeros (after all, it isn't an
> address), with the EAT in hex and the NP/OT in decimal.  Since this is a
> count (and the actual dump counts in decimal) decimal may be a better
> choice, but I don't much care.  (In principle the two numbers can be
> different.)

MS Quick View shows the same way as above, MS dumpbin show both in
decimal. If you see this amongst a pile of hexa number 

         Export Address Table            11
         [Name Pointer/Ordinal] Table    11

what do you think? Is it hexa or decimal? And in the original version 
[one is decimal other is hexa]?

         Export Address Table            18
         [Name Pointer/Ordinal] Table    24

What is hexa? What is decimal? Both is hexa just the numbers different?
Etc ... At least now you know at the first glance what's the value.

	Szaka