RE: maintainership of PEI code in BFD

[Donn Terry <donnte at microsoft dot com>]

I do subscribe to the list, and would see it someday.  However, I'm
sufficiently swamped with other things that I actually get to reading
it on the order of once a month.  Thanks for forwarding it.

PE+ (the 8 byte word part, about which I'd forgotten (and had only
heard rumors of recently)) is a problem, and it's probably another
reason to try to split things up more wisely than they have been.
(Gdb does not do at all well at debugging bfd-based programs when
support for more than one machine (e.g. alpha and i386 PE) is enabled
because it inevitably finds the wrong copy of the identically named
functions.)  (Separating PE from COFF would be extremely painful, but
otherwise would be a good idea; the relationship keeps getting more
distant.)

As far as the immediate problem, yetch.  There isn't an easy solution
to that one if you're going to try to have a single executable that handles
both PE and PE+ (which is desireable).  My inclination would be to 
leave peigen.c alone except to macro-ize it just enough so that it can
generate 2 .o files: one for all architectures for PE, and one for all
architectures for PE+.  (Since PE isn't really compatible with PE+, that
seems reasonable.)  Going back to peicode.h not only will make debugging
more painful, but it further expands the mess of "little .c including big
.h that includes big .h both of which contain lots of code", which not
exactly the nicest way of writing code I can imagine.

(In outline: compile peicode.c twice with different -D options, once for
each type.)

Donn

> -----Original Message-----
> From: David Mosberger [mailto:davidm@hpl.hp.com]
> Sent: Thursday, October 26, 2000 12:13 PM
> To: Donn Terry
> Cc: binutils@sources.redhat.com; davidm@napali.hpl.hp.com
> Subject: RE: maintainership of PEI code in BFD
> 
> 
> Hi Donn,
> 
> Did you see the follow-up discussion between DJ and myself?  It was
> sent to binutils@sources.redhat.com so if you don't subscribe to that
> list, you obviously didn't see them.
> 
> >>>>> On Thu, 26 Oct 2000 09:32:14 -0700, Donn Terry 
> <donnte@microsoft.com> said:
> 
>   Donn> That split is something more than a year old... "recently"
>   Donn> doesn't seem applicable.
> 
> Well, it turns out that your changes weren't committed to the Cygnus
> tree until after I made the EFI/PE+ related changes.  So, from my
> perspective, they were recent.  However, since you made your changes
> before the EFI/PE+ changes were committed to the CVS tree, I certainly
> see can why it was impossible for you to avoid breaking them... ;-)
> 
>   Donn> Please be more specific about what the problem is, because it
>   Donn> was my intent to separate the "generic" PE/PEI stuff from the
>   Donn> per-architecture stuff.
> 
> The main problem is that PE+ uses 8-byte fields in some places where
> PE uses 4-byte fields.  So clearly the same code cannot work for both
> cases.  I suspect what we'll need is a similar approach as for the ELF
> targets, where there is common source code that gets compiled once for
> 32-bit targets and once for 64-bit targets.  That, plus some
> additional hooks to set the EFI-specific file/section alignments and
> subsystem id probably would do the trick.
> 
> 	--david
>