<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Ingo,<br>
<br>
It appears you already did a<br>
<h1> thread-aware coredump</h1>
back in Oct 2002:<br>
<br>
<a class="moz-txt-link-freetext" href="http://lwn.net/Articles/12035/">http://lwn.net/Articles/12035/</a><br>
<br>
Your patch appears to dump the registers for all task.<br>
What happen with your idea? <br>
<br>
-piet<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid4807E877.8000404@bluelane.com" type="cite">Hey
Guys:
<br>
<br>
I've been using kgdb for a while with our 2.6.12 and now 2.6.16 kernel
<br>
as well as kdump/kexec with our 2.6.16 kernel. I'm a bit disappointed
<br>
with the visibility of local variables on the threads/tasks not
currently
<br>
running on CPUs. Both crash, and the gdb macros that you guys wrote,
<br>
show the most important stuff but I'd prefer to be able to see
everything
<br>
with gdb/ddd as I can with kgdb; including all local variables and
formal
<br>
parameters at each stack frame.
<br>
<br>
A long time ago I used gdb on SunOS 4.1.4 and use to simply set $fp
<br>
and $sp from the saved information in the U-block to view a process.
<br>
I wish gdb would allow be to run your macros, btt for example, and
extract
<br>
the stackp from task.thread.esp assign it temporally to $sp for the
current task,
<br>
do the backtrace command and see everything. Changing $sp and $fp for a
while
<br>
like I use to do with gdb on SunOS 4.1.4 and then using ddd+gdb to
browse the
<br>
stack formals and locals would be nice. Just doing a 'set write on'
isn't sufficient,
<br>
gdb wants a process and I can't see to satisfy it with simply setting
the current
<br>
thread.
<br>
<br>
I was wondering if any of you guys have been thinking of anything like
this
<br>
and had and hacks or ideas on how to see the locals and formals for all
tasks.
<br>
<br>
One thought I had was a minor hack of the kexec code to do something
like your gdb macros
<br>
and walk thru the task list and then append a ELF Notes, like done by
crash_save_this_cpu(),
<br>
for each task. I have no idea if gdb has a limit on the number of
elf_prstatus structures
<br>
that can be provided. I suppose I'd leave it a KEXEC config variable to
enable this, as
<br>
some would argue that it's not as save as simply saving the regs for
the active CPUs.
<br>
This would leave 'info threads' with gdb similar to 'ps' with crash and
virtually identical
<br>
to the experience with kgdb.
<br>
<br>
-piet
<br>
<br>
</blockquote>
<br>
</body>
</html>