<!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>&nbsp;&nbsp;&nbsp; thread-aware coredump</h1>
back in Oct 2002:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <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?&nbsp; <br>
<br>
-piet<br>
<br>
<br>
&nbsp;&nbsp;&nbsp; <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>