Re: mach-o section question
Re: mach-o section question
- Subject: Re: mach-o section question
- From: Army Research Lab <email@hidden>
- Date: Mon, 21 Apr 2008 08:35:39 -0400
- Thread-topic: mach-o section question
> ------------------------------
>
> Message: 2
> Date: Fri, 18 Apr 2008 12:50:49 -0700
> From: Andrew Myrick <email@hidden>
> Subject: Re: mach-o section question
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
>
> Send your questions to the list; I'm sure there are a few of us who
> have dealt with mach-o parsing before who would be happy to help.
> Also, check out this document:
>
>
http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/
Reference/reference.html
>
> While it's not as complete as the headers in /usr/include/mach-o/, it
> still contains good information.
I started reading it over the weekend, and have a few questions already:
1) I'm slightly confused by the ordering of sections and segments; on page
23 of the PDF of the Mac OS X ABI Mach-O File Format Reference (the PDF
complement of the link Andrew sent me above), says that the section commands
for a segment directly follow the segment they are a part of, but Fig. 1
implies all the segments are grouped together, and then all the sections
follow after that; which is happening?
2) I know that sections are numbered started at 1; what happens if I created
a section with a number of 0? If I created my own linker, would I need to
reserve space for a section 0?
3) According to the note on page 12, tools are allowed to define addition
section names; do they need to be registered with Apple in some way to
prevent namespace problems?
4) There is an __OBJC segment; are we allowed to create addition segment
names, or will that throw off the loader? If we can create new segments,
then question #3 can go away, as anything that needs to be tossed into its
own section can go into the segment instead...
5) The uuid_command referenced on page 20 uses a 128 bit UUID; is this
expected to be the output of uuid_generate(), or will any 128 bit UUID
generator work (in short, is there hidden info in the UUID that I need to
keep straight)?
6) I notice that there are a number of structs (e.g. section, defined on
page 23) that have 16 element char arrays for their section names, and the
docs say ASCII characters; that is a little imprecise, which set of
characters are allowed? Also, does the string have to be NULL terminated?
More importantly, should all characters that aren't part of the name be set
to NULL? Pure guess suggests that you'd memset() to 0, and then only use
characters for which isgraph() returns true.
In case you're all wondering why I'm asking so many questions, it occurred
to me over the weekend that one of the best ways of learning about a file
format is to make a full reader/writer for it, from scratch. I doubt I'll
really complete such a project, but I'd like to start on it at least. My
goal is to write it in pure Python; that prevents me from cheating, and
thinking I know how something works, when I really don't. It also means
that there will be second implementation of the written standard out there,
which should turn up any bugs in the docs, and may also turn up bugs in the
loader.
Thanks,
Cem Karan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden