Re: mach-o section question
Re: mach-o section question
- Subject: Re: mach-o section question
- From: David Elliott <email@hidden>
- Date: Wed, 16 Apr 2008 13:30:07 -0400
Hi Cem,
What you really want is the "Mac OS X Assembler Reference",
specifically "Directives for Designating the Current Section"
http://devworld.apple.com/documentation/DeveloperTools/Reference/Assembler/ASMDirectives/chapter_5_section_2.html
That doesn't explain absolute or common symbols. Absolute are pretty
easy to explain. With the assembler you can define a symbol with an
absolute address which is quite useful when you have some binary
interface that depends on this.
For example, from a C file you could prototype extern void
_commpage_bcopy(const void *src, void *dst, size_t len); Then from an
assembler file you could specify a __commpage_bcopy symbol at exactly
0xffff0780. You should not do this because that's not an official ABI
but if you do something like x/10i 0xffff0780 from gdb on an Intel mac
with an Intel program you will clearly see that this is bcopy. Or
rather _bcopy (in C, hence __bcopy from gdb). Whether Apple uses an
absolute symbol to achieve this or not is not the concern here, the
point is that you could do it and this just illustrates a particular
real-world potential use of it. In this case, the contents of memory
at that address are actually mapped into all processes by the kernel,
that's why all Intel processes on OS X can see it there.
As for common symbols, it's perhaps a bit of a hack. Consider two C
source files that do this:
int foo;
In this case if you did not use common symbols the compiler would have
to generate assembler statements that allocate 4 bytes (assuming 32-
bit int) from the __DATA,__bss section. When you then linked the two
resulting object files together you would get a duplicate symbol
error. Granted the correct modern code would be for one file to
declare int foo; and all the others to declare extern int foo;. The
compiler by default uses -fcommon (to turn it off use -fno-common
which is listed in the manpage). That means that any time the
compiler sees an uninitialized variable declaration it treats it
basically as if it was declared extern.
If you really want to understand it further, perhaps you should use
gcc's -S option so you can get a feel for the assembler statements
that the compiler uses.
Normally you should only see common in .o files. Once they are linked
into an executable, bundle, or dylib they are allocated by the link
editor (ld) into __DATA,__common.
Also, otool -lV will show you quite a bit of information on the load
commands. The capital v makes it display in non-numeric verbose mode
so for example you see the flags as names instead of hexadecimal
bitmasks.
Please don't go off and do something foolish like use bcopy directly
from the commpage in some shipping app just because you can. This
information is merely to satisfy your curiosity, nothing more.
-Dave
On Apr 16, 2008, at 10:36 AM, Army Research Lab wrote:
Hi all, I'm working on writing a command line scraper for the output
of the
'nm' command written in Python. For right now, the only things I'm
interested in are the lines output by the command
'nm -gmf foo.o | c++filt -_'. This applies to anything that nm can
parse,
not just .o files. Although it isn't 100% necessary for what I'm
doing, I
am curious as to what the various sections in the mach-o binaries
are. As a
brief, but incomplete list, here is what I've seen so far:
__DATA,__common -- Uninitialized imported global symbols
__DATA,__data -- Initialized mutable variables
__TEXT,__cstring -- Constant C-strings
__TEXT,__eh_frame -- ???
__TEXT,__literal8 -- ???
__TEXT,__text -- Executable machine code
__TEXT,__textcoal_nt -- ???
absolute -- absolute addresses - start up code?
common -- ???
Can anyone fill me in on what those unknown sections are? I briefly
looked
at the Mac OS X ABI Mach-O File Format Reference
(http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORun
time/Reference/reference.html), which is where I got the few
definitions I
have above, but I'd like to know more.
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
_______________________________________________
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