Re: Accessing Thread Information in kernel crash dumps with ddd+gdb

From: Vivek Goyal <vgoyal@redhat.com>
To: Piet Delaney <pdelaney@bluelane.com>
Cc: Bernhard Kaindl <bk@suse.de>, Andrew Morton <akpm@osdl.org>,
	V Srivatsa <vatsa@in.ibm.com>,
	Sergei Shtylyov <sshtylyov@ru.mvista.com>,
	Milind Dumbare <jhumo2002@yahoo.com>,
	"Amit S. Kale" <amitkale@linsyssoft.com>,
	Jason Wessel <jason.wessel@windriver.com>,
	kexec@lists.infradead.org, Andrew Cagney <ac131313@cygnus.com>,
	Bernhard Walle <bwalle@suse.de>,
	George Anzinger <george@mvista.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Vivek Goyal <vgoyal@in.ibm.com>,
	Dave Anderson <anderson@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>, Maneesh Soni <maneesh@in.ibm.com>,
	Castor Fu <Castor.Fu@3PAR.com>,
	Alexander Nyberg <alexn@telia.com>,
	Joel Brobecker <brobecker@adacore.com>,
	Daniel Jacobowitz <drow@false.org>
Subject: Re: Accessing Thread Information in kernel crash dumps with ddd+gdb
Date: Fri, 18 Apr 2008 10:10:28 -0400	[thread overview]
Message-ID: <20080418141028.GB1983@redhat.com> (raw)
In-Reply-To: <4807E877.8000404@bluelane.com>

On Thu, Apr 17, 2008 at 05:16:55PM -0700, Piet Delaney wrote:
> 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.

IIUC, you are suggesting that we create elf notes even for non-active
tasks in vmcore. We should not be doing that.

- It is not safe to traverse through task list after system has crashed.
- We reserve the memory for elf notes at system boot. At that time we
  have no idea how many task system will have at the time of crash.

I think following can be a way forward for your requirement.

- Either gdb should provide a SunOS kind of facility where one can 
  provide stack pointer and switch the task context. ( I don't know
  if there is already a way to do that).

- Or one can write a user space tool, which parses original vmcore,
  walks through task list, prepare elf notes for all the tasks and emit
  a new vmcore which is fetched to gdb.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec