Re: pef.c:bfd_pef_object_p breaks other targets

[Klee Dienes <klee at apple dot com>]

Yes; I was hoping to get away with it using a rationale of "but what 
other target could possibly match 'Joy!peff' as the first 8 bytes".

I've modified all three targets (pef, mach-o, and sym) to save and 
restore the bfd state using the functions 
bfd_preserve_save/restore/finish before any modifications to tdata or 
the arch.  I chose to cut-and-paste the three functions between the 
files to simplify things; I'd be happy to factor them out into a 
separate file if you prefer (and if you can suggest a good filename).

To avoid going insane while trying to manage our local sources, I've 
simply appended the ChangeLog entries from this patch to those of the 
previous (proposed) patch.  The full entry is in the patch file.

Attachment: pef-macho.txt
Description: Text document

On Monday, November 11, 2002, at 05:34 PM, Alan Modra wrote:

> On Sun, Nov 10, 2002 at 11:27:53PM -0500, Klee Dienes wrote:
> > I've changed pef_object_p, pef_xlib_object_p, and sym_object_p to only
> > trample abfd->tdata if the targets pass the magic-number check (in the
> > case of pef, the first 8 bytes must be "Joy!peff"; for xsym, the first
> > 32 bytes must match "\013Version 3.x" followed by 20 nulls, both of
> > which seem pretty safe).
> You still have bogus assignments to abfd->tdata.  Please get rid of
> them all.  On exit from xxx_object_p you should not have changed
> tdata when returning NULL.
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre