site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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; 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. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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! 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. This email sent to site_archiver@lists.apple.com