This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]