RE: maintainership of PEI code in BFD

[Donn Terry <donnte at microsoft dot com>]

That would also work, and "following the leader" isn't really a bad idea.

Although I'm personally very interested in the IA64 side of this, bandwidth
just isn't there at the moment to do anything about it.

Donn

> -----Original Message-----
> From: Ian Lance Taylor [mailto:ian@zembu.com]
> Sent: Thursday, October 26, 2000 2:23 PM
> To: Donn Terry
> Cc: davidm@hpl.hp.com; binutils@sources.redhat.com
> Subject: Re: maintainership of PEI code in BFD
> 
> 
>    From: Donn Terry <donnte@microsoft.com>
>    Date: Thu, 26 Oct 2000 12:55:38 -0700
> 
>    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.
> 
> Do it the way ECOFF does it (I wrote most of the ECOFF backend, so I
> like it).  There is 32 bit ECOFF for MIPS, and 64 bit ECOFF for Alpha.
> We define the internal structures using bfd_vma.  The generic code
> (ecoff.c and ecofflink.c) uses a struct of function pointers to call
> the appropriate swap routine (struct ecoff_backend_data).  The swap
> routines are defined in ecoffswap.h, which is (alas) compiled twice.
> 
> Ian
>