Re: [PATCH/RFC] Add support for PEF, Mach-O, xSYM

[Klee Dienes <klee at apple dot com>]

Thanks for the feedback.  The attached patch should fix a number of the 
issues you mention.

I should warn you that Apple's support for PEF and xSYM in GDB is 
primarily for legacy purposes.  I'm glad to see people taking an 
interest in it, and I'm certainly happy to hack on it as time permits, 
but I don't have much day-to-day contact with PEF and xSYM files.

On Sunday, October 13, 2002, at 12:47 AM, Segher Boessenkool wrote:

> xSYM:
>
> *	bfd_sym_object_p() doesn't clear abfd->tdata.sym_data; this leads
> to crashes if binutils is autodetecting formats (I configure binutils
> with --enable-targets=all; so I run into this).
Fixed.  We run with --enable-target=all as well; we just have some 
local changes to target.c that tend to insulate us from (abfd->tdata.X 
!= NULL) issues.

> PEF:
>
> *	Every section gets the same section flags now; but not every section
> should have CODE and/or LOAD set.  Maybe other such flags as well.  
> This
> is a nuissance if using objdump --disassemble, for example.
I added a new function to set the load flags for a bfd section based on 
the PEF section type.  Currently the only difference is that CODE 
doesn't get set for non-code sections; I'd welcome any more flags that 
should be set/unset for various PEF types.

> *	architecture doesn't get set; it's in the PEF header bytes 8-11.
Fixed.

> *	All sections seem to have LMA == VMA; is this correct?
I think so, though I'm not sure how relevant the idea of LMA is to a 
pef file, so I can't really say for sure.

> *	I think the executable entry point doesn't get set.
I added new code to parse the entry point field out of the loader 
vector, but I'm not really sure how to interpret it.  Do you have a 
file you could point me to with a correctly set entry point and a 
(brief) explanation of what the offset in the field is actually an 
offset into?

> *	bfd_parse_function_stub() assumes all the transition vectors are in
> one table, starting at offset 0.  This is not true in general (I think 
> it's
> true for some compilers, but not for others).
>
> *	It would be useful to generate a label for the generic cross-module
> call stub, as well (all files I've seen have it right after the 
> "normal"
> stubs; but its code pattern is just as recognizable as the normal stub
> pattern, so better use that).
Might you have an example file that makes use of either of these?  I'm 
happy to hack on them, but having a "this file should generate the 
following output" test-case would help a lot.