RE: bfd/peigen.c problems and fix

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

On Thu, 11 May 2000, Donn Terry wrote:

> 4) Changing so it will believe the DataDirectory even in the presence
>    of an .idata or .edata section.  I've never seen a situation where
>    there is a .idata or .edata, AND the DataDirectory doesn't point to
>    .idata (resp .edata) 

Doesn't matter. The original code was broken since it didn't set the
dataoff properly. objdump from Mingw still segfaults on some dll's and it
uses some of the last non-PEI-broken binutils plus some fixes.

>    but I don't see that the change hurts anything.

Actually it improves ;) Now you can dump pei files that you couldn't
before because objdump just coredumped.

>    (My objective in writing the code that way was to preserve the (long)
>    prior behavior of using .idata or .edata exclusively, and to fall
>    back to the DataDirectory only in their absence.  If no-one cares

Sorry but this is a wrong idea and won't work. Not all PEI files 
constructed this way in the real world. 

> I built the exact CVS bits (from a few days ago), without change (and
> just tested objdump).  It works fine on MSVC4 executables, but for MSVC5
> (and 6) executables, it still chokes due to an object file format change.
> (It doesn't recognize the file type.  That includes DLLs included in win2k,
> by experiment).  There's code there to fix it, but it doesn't quite
> work.  I have a fix for that, so if folks can wait until I get that
> signature....

It worked before and Mingw objdump still works with them, why was it
break? Could you please give some estimates for the fix? If it
would take too long, I'll look at it. Thanks.

	Szaka