Re: [Fastboot] kexec+kdump testing with 2.6.12-rc3-mm3

[Alexander Nyberg <alexn@telia.com>]

> Probably you need another loop here for iterating thr' all the
> threads of a task? do_each_thread/while_each_thread macros give
> the details.
> 
> Basically the macros can be modified as:
> 
> set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
> set $pid_off=((size_t)&((struct task_struct *)0)->pids[1].pid_list.next)
> set $init_t=&init_task
> set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
> while ($next_t != $init_t)
> set $next_t=(struct task_struct *)$next_t
> printf "\n%s:\n", $next_t.comm
> printf "PID = %d\n", $next_t.pid
> printf "Stack dump:\n"
> x/40x $next_t.thread.esp
> set $next_th=(((char *)$next_t->pids[1].pid_list.next) - $pid_off)
> while ($next_th != $next_t)
> set $next_th=(struct task_struct *)$next_th
> printf "\n%s:\n", $next_th.comm
> printf "PID = %d\n", $next_th.pid
> printf "Stack dump:\n"
> x/40x $next_th.thread.esp
> set $next_th=(((char *)$next_th->pids[1].pid_list.next) - $pid_off)
> end
> set $next_t=(char *)($next_t->tasks.next) - $tasks_off
> end

When looking at this I thought of what information we want to save in
the ELF header to be examined after a crash. I'm currently working on
some patches to save all threads in the kernel down into the PT_NOTE
section. But do we really need this if we instead have a suite of gdb
scripts and other user-space analyzers that can find the requested
information?

This would simplify aspects such as not having to fiddle with the crash
ELF header in the kernel. I can't see a gain in dumping a bunch of
NT_PRSTATUS or NT_TASKSTRUCT in the notes section if we can find the
same information in gdb/user-space after a crash-dump.

We should be able to get get (symbol) backtraces from each task with
some gdb scripts too, so I think most analyzis can be done from
user-space. Am I missing something?

All tasks running on a cpu should be saved into NT_PRSTATUS notes
ofcourse, as they are currently. The have a (very) useful pt_regs plus
some other information such as trap number causing the panic or the
address of where the fault occured.