Home Original page

BFD patch for peicode.h

DJ Delorie dj@delorie.com
Thu Jun 22 21:16:00 GMT 2000 
> Also, I'd appreciate if we could find a way to make it less likely
> that changes to the PECOFF support break the EFI support.

I suggest automated build/test machines for targets that you want to
keep in a good state.  Unfortunately, automated testing on PE machines
isn't trivial.  I do cross-builds for cygwin every night.

> This appeared to happen whenever the binary contained a section that
> was not completely inside the address range
> [ImageBase,ImageBase+SizeOfImage).  Based on this I concluded that
> SizeOfImage probably should be calculated as the difference between
> the highest address in the binary and ImageBase (the PECOFF doc I have
> is less than clear on this topic) and this is what the attached patch
> is trying to do.

Based on what I read in MSDN, I agree that it's the size of the
virtual image *in memory*.  I don't know if it includes the
non-program sections, though, like the import table.  We've never had
problems with NT or CE wrt this field, but then NT is pretty lax about
what it runs.

> Could a PECOFF expert review this and merge it into the official
> tree if it looks right?

We're woefully short on PE experts at the moment :-(

> On a related note: I noticed that the BFD tree on sourceware has
> completely broken EFI support.

Sourceware has broken *PE* support at the moment, which I'm trying to
fix.  PE has been fairly unusable since Sept 1999.

> 2000-06-22  David Mosberger  <davidm@hpl.hp.com>
> 
> 	* peicode.h (coff_swap_aouthdr_out): Compute SizeOfImage as
> 	difference between highest section address and the ImageBase.
> 
> --- orig/bfd/peicode.h	Fri Feb 18 14:39:16 2000
> +++ src/bfd/peicode.h	Thu Jun 22 17:36:01 2000
> @@ -1119,7 +1119,7 @@

What is this patch against?  In sourceware, that function is in
peigen.c and looks nothing like what you're patch is against.
More information about the Binutils mailing list