You are running into the general case that low level system interfaces
are generally not extremely well documented as far as their internals
or design philosophy is concerned.
We compile each system call stub or decorated symbol for a library
routine once per decoration. Each gets its own .o file. Then all
versions of the .o file get added to the library, resulting in a
library containing all versions of the symbol. In addition, there are
default aliases. These tend to refer to the legacy behaviour for the
benefit if older programs, but in some cases will refer to the new
behaviour (new interfaces, or routines called from new interfaces).
For example, x and x$UNIX2003 would refer to the function x legacy
linkage, and x which is UNIX conformant. How this actually works
depends on the call implementation.
As a specific example, for 'kill', it means there's a second hidden
parameter in the contract between the bottom of libSystem and the top
of the kernel, and it gets the value of 0 or 1 based on whether or not
a kill sent to a process group will also be sent to the caller
(required by UNIX) or not (required for binary compatibility wi legacy
applications that do not expect to handle a signal they send to their
own process group). The library itself doesn't expose this contract at
all.
As another example, the difference in the error codes "ENOTSUPP" and
"EOPNOTSUP" are mandated by UNIX to distinguish socket-specific non-
support from general non-support, so they are required to have
distinct values. In legacy systems, translation of the new EOPNOTSUP
value for old software which hard codes error checking, instead of
handling all errors, is done in an assembly error return stub for the
call.
Yet other methods are used elsewhere.
If you are just wrapping the libSystem routines, and plan to call our
functions after doing whatever your interposition layer does, you
generally only need to create corresponding stubs for all functions.
If you are planning anything else, well, start by learning how to
build libSystem from the published sources, and make your changes
relative to that.
Also, if you don't need to interpose everything... don't! The Malloc
debug library is an example of only interposing the symbols you need
to, and leaving everything else alone. Take that approach, if at all
possible.
-- Terry
On Mar 13, 2008, at 8:45 PM, Luke Daley <email@hidden> wrote:
On 14/03/2008, at 12:51 PM, Terry Lambert wrote:
I have written an implementation of read(int, void*, size_t)
that I
am trying to use via DYLD_INSERT_LIBRARIES. I have this working
fine
on 10.4, but not on 10.5.
I have read http://lists.apple.com/archives/Darwin-dev/2007/Nov/
msg00061.html but am still not clear on what I need to do. A
follow
up to that post mentions including a header. I can't seem to
find any
detail on this header.
Look at the function prototype declaration in <unistd.h> on
10.5. You have to do yours the same way. Macros are defined in
<sys/cdefs.h>.
Specifically, I think I need to provide all 3 symbols (_read, _read
$UNIX2003 and _read$NOCANCEL$UNIX2003) for this to work.
The thing that's killing you is you are using -mmacosx-version-
min=10.4
When we compile Libc, we compile it three times in order to get the
three versions of the symbols, once each with different
definitions. You'll never get the $NOCANCEL version of the symb
(the one that avoids the _thread_testcancel() at the start of the
system call in the kernel) on a 10.4 deployment target.
Thanks Terry.
Just to clarify, I need to build three different dylibs? There is no
way to produce one dylib with all three symbols? Apologies for what
may be obvious questions. I am a bit out of my depth here.
Thanks.
LD.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
