Accessing Thread Information in kernel crash dumps with ddd+gdb

[Piet Delaney]

Ingo,

It appears you already did a


      thread-aware coredump

back in Oct 2002:

        http://lwn.net/Articles/12035/

Your patch appears to dump the registers for all task.
What happen with your idea? 

-piet


   

> Hey Guys:
>
> I've been using kgdb for a while with our 2.6.12 and now 2.6.16 kernel
> as well as kdump/kexec with our 2.6.16 kernel. I'm a bit disappointed
> with the visibility of local variables on the threads/tasks not currently
> running on CPUs. Both crash, and the gdb macros that you guys wrote,
> show the most important stuff but I'd prefer to be able to see everything
> with gdb/ddd as I can with kgdb; including all local variables and formal
> parameters at each stack frame.
>
> A long time ago I used gdb on SunOS 4.1.4 and use to simply set $fp
> and $sp from the saved information in the U-block to view a process.
> I wish gdb would allow be to run your macros, btt for example, and 
> extract
> the stackp from task.thread.esp assign it temporally to $sp for the 
> current task,
> do the backtrace command and see everything. Changing $sp and $fp for 
> a while
> like I use to do with gdb on SunOS 4.1.4 and then using ddd+gdb to 
> browse the
> stack formals and locals would be nice. Just doing a 'set write on' 
> isn't sufficient,
> gdb wants a process and I can't see to satisfy it with simply setting 
> the current
> thread.
>
> I was wondering if any of you guys have been thinking of anything like 
> this
> and had and hacks or ideas on how to see the locals and formals for 
> all tasks.
>
> One thought I had was a minor hack of the kexec code to do something 
> like your gdb macros
> and walk thru the task list and then append a ELF Notes, like done by 
> crash_save_this_cpu(),
> for each task. I have no idea if gdb has a limit on the number of 
> elf_prstatus structures
> that can be provided. I suppose I'd leave it a KEXEC config variable 
> to enable this, as
> some would argue that it's not as save as simply saving the regs for 
> the active CPUs.
> This would leave 'info threads' with gdb similar to 'ps' with crash 
> and virtually identical
> to the experience with kgdb.
>
> -piet
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.infradead.org/pipermail/kexec/attachments/20080417/2a8f795f/attachment.html