Re: Programmatic Back Trace
Re: Programmatic Back Trace
- Subject: Re: Programmatic Back Trace
- From: Geoffrey Schmit <email@hidden>
- Date: Wed, 3 Sep 2003 11:30:54 -0500
On 03.09.2003 at 11:06 AM, Jim Magee <email@hidden> wrote:
>
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?
I'm primarily interested in getting a kernel backtrace from my kernel
extension. I'm porting a library that provides various services to
other kernel extensions we develop. One of these services is to capture
a backtrace. For example, we may capture a backtrace when a kernel
extension detects an error in order to facilitate the debugging of that
error condition. As another example, we may capture a backtrace when a
kernel extension acquires a resource in order to later determine who
acquired that resource if the resource is leaked.
Ideally, it would be beneficial for the backtrace to eventually include
the stack of the user-mode thread that initiated the transition to the
kernel (in scenarios where this is the case). However, that is probably
pushing my luck....
I'm not at all interested in developing a kernel extension to capture
user-level backtraces from arbitrary processes.
>
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.
So, my problem is probably that as I walk the stack I eventually
encounter an address from a user-mode thread and cause a panic. Is
there a way to test if the address belongs to the kernel or otherwise
determine that I should stop walking the stack?
If further clarification would be helpful, please let me know.
Thanks!
geoff
_______________________________________________
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.