This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: BFD patch for peicode.h
- To: davidm at hpl dot hp dot com
- Subject: Re: BFD patch for peicode.h
- From: DJ Delorie <dj at delorie dot com>
- Date: Fri, 23 Jun 2000 00:16:04 -0400
- CC: binutils at sourceware dot cygnus dot com
- References: <200006230357.UAA14807@napali.hpl.hp.com>
> 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.