Re: kdebug_chudhook: need finer grained kdebug
Re: kdebug_chudhook: need finer grained kdebug
- Subject: Re: kdebug_chudhook: need finer grained kdebug
- From: Terry Lambert <email@hidden>
- Date: Wed, 29 Nov 2006 13:35:05 -0800
On Nov 29, 2006, at 1:36 AM, Robert Kueffner wrote:
Hi,
the kdebug trace facility provides kernel event logs via
typedef struct {
uint64_t timestamp;
unsigned int arg1;
unsigned int arg2;
unsigned int arg3;
unsigned int arg4;
unsigned int arg5; /* will hold current thread */
unsigned int debugid;
} kd_buf;
Logs sampled over some time interval are retrieved by existing
commands (sc_usage, latency etc) and a program described in Singh's
OSX internals, Fig 6-39. The value of the debugid-field denotes the
invocated function, corresponding names given in /usr/share/misc/
trace.codes
MY PROBLEM
1) I need to extract the particular parameters and returned values,
say in the case of MACH calls.
2) I need to perform actions immediately after starting/before
finishing an operation, instead of just processing logs
I found that (mig generated) messages requesting (as well as
replying to) the operations are also traced. arg1 & arg3 give the
message address in memory and its size. At the time logs are
retrieved the contents of these messages is most likely lost,
though, so parameters etc are not available.
SOLUTION?
A solution could be to register a kdebug_chudhook() callback to
retrieve the logs including the messages during their transmission.
As far as I understood, CHUD itself does not seem to export this.
(although chudMaxKDebugTraceSampleLimitCallback() sounds related, an
undocumented funtion from chudKDebugTrace.h)
Does anybody know how to register a kdebug_chudhook() callback?
(I am aware this would be a kernel context callback that must not be
messed up)
Is there a more straightforward solution?
Any help is greatly appreciated!
The short answer is "don't do this".
The next shortest answer is "why do you want to do this?".
After that, the answers get longer.
In general, you cannot trap kernel entries or exits, and even if you
were able to do so by abusing this monitoring trace record cutting
mechanism, it only applies to processes that are currently being
ktrace'ed, and then it's only a notification mechanism. In other
words, whatever actions you perform will have to be non-destructive -
not change any of the arguments into, or any of the results out of, a
given system call or Mach call.
Technically, it's possible to abuse this with knowledge of the
specific call graph and assembly code involved, to get at the spill
area and register spills from function calls in progress on the stack,
and hack around arguments (if I can do it, I'm sure someone else can
figure out how to do it, after all), but there's no guarantee that
this type of hack would not break on each and every software update,
so it's not like you could use this approach to make a useful product
that would not need continuous ongoing maintenance and probably result
in a lot of bug reports to Apple that aren't Apple's fault.
So now we are back to the next shortest answer of "why do you want to
do this?".
It's likely that, if you tell us the problem you are trying to solve -
i.e. something less generic than "I want to hook all the system calls
for some unspecified and probably nefarious reason" - then we can
probably give you a couple of better approaches to solve the actual
problem you want solved, without doing anything that makes you
dependent on implementation details we won't promise not to change, or
likely to break you or someone else down the road.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden