Re: generating mach-o executable files by hand
Re: generating mach-o executable files by hand
- Subject: Re: generating mach-o executable files by hand
- From: Terry Lambert <email@hidden>
- Date: Wed, 07 Jan 2009 06:48:12 -0800
On Jan 7, 2009, at 1:24 AM, Joel Reymont <email@hidden> wrote:
Terry,
On Jan 7, 2009, at 3:33 AM, Terry Lambert wrote:
You have to use at least *a* linker; if you don't, you won't be
able to import the system call stubs from libc/libsystem
I hope to prove you wrong, shortly. This is a Forth so all I need is
stubs for dlopen, dlclose, dlsym and dlerror. I also need to jump to
an entry point. This works fine on Linux with the ELF format.
I don't know how soon it will be, even with the broad strokes I'm
about to outline to illustrate the complexity and fragility over
updates of what you are attempting.
I'm not sure if Linux uses the SVR4 trick of starting the first page
of a process at a large virtual offset and always mapping ld.so into
the low memory hole starting a 4k or not.
I do know that there is a load command in Mach-o that causes dyld (the
moral equivalent of ELF ld.so) to be loaded, and that the linker
relocates things so that the default thread state struct program
counter vale in another load command points to the start address of
the dyld start routine, NOT the entry point for your compiled program.
After that, after the segment loads (which just establish mappings),
the kernel ignores all of the other load commands besides the unix
thread state structure, and dyld does the rest based on the other
sections.
The dlopen et. al. bindings are things that know how to refernce into
the dyld (unlike in Linux ELF, where they are static stubs in crt1
that are built with apriori knowledge of where ld.so gets loaded, dyld
is permitted to "slide" if necessary, and do does not maintain a
nrcessarily fixed location).
There is no ELF-like hierarchical linking library against library to
ensure visibility of pre-linked code symbols via dlsym.
While you may be able to do this on the basis of bundle-style
operations, rather than dlopen, you are likely not going to be happy
with the results due to the dependence on a non-flat namespace.
I also rather expect you aren't going to get help from the tools folks
to deal with these issues, or to document how to generate a valid Mach-
o.
Completely apart from any correctness considerations, we don't promise
we won't change all the implementation details at some point in the
future, and documenting how things currently work at the level of
detail you'd need would likely set certain details in stone which we'd
rather not have be that static.
And that's all without dealing with the vtable offsets and library
preinitialized data and constructors/destructors, or the other
necessary symbol relocation (even assuming you are writing PIC-only
instructions and using the slightly-different-than-Linux calling
conventions).
You will be better off invoking the linker.
-- Terry
_______________________________________________
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