Re: Interposing library calls
Re: Interposing library calls
- Subject: Re: Interposing library calls
- From: Terry Lambert <email@hidden>
- Date: Fri, 25 Jul 2008 12:21:56 -0700
On Jul 25, 2008, at 5:17 AM, Jernej Azarija wrote:
Hello,
this is a continuation of the previous thread located in darwin-kernel
at : http://lists.apple.com/archives/Darwin-kernel/2008/Jul/msg00015.html
.
I assume my question is more on topic here.
The conclusion reached in the above mentioned thread is that it's
preferred to interpose library calls (in this case open/close) from a
library loaded at runtime. I've therefore created a small example
trying to intercept open, resolve the given path (using realpath()),
print the resolved path and pass the work to open().
For these things to work, you need a relatively deep understanding of
the ABI and linkage model.
Quinn is correct that library interpostion is not officially supported
by Apple. In general, this is because you will have to lock-step
update your library with system library updates from Apple. The
specific example I had in mind when I read Mike's suggestion on
interposition is probably the same one Mike had in mind. Mine was
"mallocdebug" (Mike used to maintain it, so that's why I'm guessing
it's his example).
It's possible to interpose, but you have to understand the lock-step
nature of interposition, along with the nature of the library
implementation, and the use of multi-level namespaces within
libraries. The best source example is "mallocdebug", but again, you
should be cautioned that what you want to do will have to be lock-
stepped.
Objective-C based code was intended to support runtime overrides as a
language feature; you can still run into problems with library
compatibility there, but it's less frequent when you follow the rules.
[ ...]
I'm clueless about what is causing this issue. As far as I've checked
libc' implementation, getcwd() is not using open() (at last not
directly). I'd be glad to hear a hint on how to overcome this issue.
__getcwd() uses open to get ".", then asks the system for the path to
".". Depending on the answer it gets, it may go and ask for ".."
recursively until it gets all path components to the root of the
volume. You appear to be interposing open at the wrong level in the
symbol namespace, so getcwd() is calling your open() rather than the
system open().
The difficulty in getting this type of detail right is another reason
it's not supported. You are also unlikely to get it right to the
point that multiple libraries can interpose the same set of calls, so
if someone else tries to do what you are trying to do at the same
time, one of you is going to be unhappy.
Ps. I'm aware that this method is not officially "supported" by Apple,
neither is any kernel "hacking" of this type. All this makes me
wonder, how is someone able to deploy applications if it can't use
internal information - in my opinion, forcing people not to mess with
this stuff is just encouraging bad design of applications.
The general cause of problems like the ones you are running into is
usually that you are asking about how to implement a solution to a
problem, when you've already arrived at the solution. Typically, it's
better to ask "how do I solve this problem?" rather than "how do I
implement this solution which I've already arrived at?", since you'll
likely get more useful answers.
-- 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