Re: Programmatic Back Trace
Re: Programmatic Back Trace
- Subject: Re: Programmatic Back Trace
- From: Jim Magee <email@hidden>
- Date: Wed, 3 Sep 2003 11:06:42 -0400
On Sep 3, 2003, at 10:23 AM, Geoffrey Schmit wrote:
I'm currently stuck trying to find a function that is accessible by a
kernel extension and that is equivalent to vm_read_overwrite in that it
will return an error if the specified address is inaccessible rather
than throwing a SIGSEGV signal.
So, a couple of questions:
Is there an example that captures a back trace in a kernel extension?
If so, where is it?
Are you trying to get a user-level backtrace or a kernel backtrace from
your kernel extension? And more importantly, why are you doing this
from a kernel extension in the first place? Maybe if you are writing a
new whole-system/kernel debugger or something. But looking at
user-space backtraces (or memory in general) from random points in the
kernel is extremely touchy stuff and highly likely to kill the whole
system if done at the wrong point.
Not to pick on you in particular, but to make a point in general, the
kernel is not always a better place to stuff "everything." Far fewer
things work reliably within the kernel than outside. And our system
provides "much sharper" tools outside the kernel than a typical Unix
system - so far fewer things need to be in the kernel in the first
place. Remember, the tools are so sharp that, in theory, even "the
kernel" doesn't need to be in the kernel. ;-)
If I can't, any suggestions on other ways to achieve my goal? For
example, can I catch the SIGSEGV signal, set an error condition, and
continue execution?
In-kernel, if you access memory you don't have mapped, you're dead
(panic). You don't get a signal to respond to. And, besides, you can't
directly access any user-level memory at all. On PowerPC, user-memory
isn't mapped into the kernel's view of memory, since the kernel gets it
own 4GB address space. i386 is slightly different, but changing more
towards the PowerPC model than the other way around.
If you are always running in the execution context of a thread that is
part of the process you are trying to access, you can do "copyin()."
And if you are always in a clean state, you can even use
vm_read_overwrite() (taking into account in-kernel semantics of such
calls). But I highly recommend doing all this from outside the kernel
if at all possible (have your kext block the thread in question so that
the out-of-kernel process will always find the process alive if
necessary).
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.