Re: Programmatic Back Trace
Re: Programmatic Back Trace
- Subject: Re: Programmatic Back Trace
- From: Geoffrey Schmit <email@hidden>
- Date: Tue, 9 Sep 2003 15:40:46 -0500
On 03.09.2003 at 2:22 PM, Chris Thomas <email@hidden> wrote:
>
I have a need (well, a strong desire) for this myself right now.
>
>
http://developer.apple.com/technotes/tn2002/tn2063.html has
>
information which may be pertinent: it lists the source files used to
>
generate the textual kernel panic, ie:
>
>
> Line 6 xnu/osfmk/ppc/model_dep.c: dump_backtrace
>
>
It's not immediately clear to me whether or not this code is useful
>
outside of an exception context.
Thanks for the information; model_dep.c was quite helpful. The
dump_backtrace function does basically what I need. I was able to
easily integrate its logic into my library and now have the ability to
capture kernel backtraces.
Thanks again!
geoff
>
On Sep 3, 2003, at 9:30 AM, Geoffrey Schmit wrote:
>
>
> 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?
--
Geoffrey Schmit
Senior Software Engineer
National Instruments
email@hidden
www.ni.com
_______________________________________________
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.