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: Klee Dienes <klee at apple dot com>
- To: Segher Boessenkool <segher at koffie dot nl>
- Cc: binutils at sources dot redhat dot com
- Date: Mon, 4 Nov 2002 16:45:42 -0500
- Subject: Re: [PATCH/RFC] Add support for PEF, Mach-O, xSYM
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.