This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH/RFC] Add support for PEF, Mach-O, xSYM
- From: Segher Boessenkool <segher at koffie dot nl>
- To: Klee Dienes <klee at apple dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 06 Nov 2002 00:03:21 +0100
- Subject: Re: [PATCH/RFC] Add support for PEF, Mach-O, xSYM
- References: <C3F97ED8-F03E-11D6-8361-00039396EEB8@apple.com>
Klee Dienes wrote:
>
> Thanks for the feedback. The attached patch should fix a number of the
> issues you mention.
I thank you -- binutils PEF support is quite useful to me.
There's no attached patch, btw, so I can't review -- please resend?
> I should warn you that Apple's support for PEF and xSYM in GDB is
> primarily for legacy purposes.
I don't think anyone would think otherwise. Too bad -- I like PEF a lot.
> > 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.
I'll see what I need, and prepare a patch if needed.
> > * 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.
Well, as it was when I tested, the offsets in the disassembly were
file offsets, i.e. the first byte of the code section was not at
offset 0. I don't think this is correct.
> > * 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?
"section" is a PEF section number, "offset" is an offset in that section;
it points at a TVECTOR8 (that is, offset + section number) which is the
code address.
A picture is worth a thousand words, so:
Loader header data section code section
(section# + offset) --> (section# + offset) --> (the actual code)
> > * 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).
I'll try to find an example file.
> > * 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).
See the "Mac OS Runtime Architectures" (jan 31, 1997) book, page 2-11.
> 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.
I'll follow up on this later.
Thanks,
Segher