Re: [announce] kdump2gdb: analyze kdumps with gdb (well, almost)

[Jean-Marc Saffroy <saffroy@gmail.com>]

Hello Vivek,

On Mon, 9 Oct 2006, Vivek Goyal wrote:

> On Fri, Oct 06, 2006 at 06:42:00PM +0200, Jean-Marc Saffroy wrote:
>> Hello folks,
>>
>> Following earlier discussions on how nice it would be to use gdb on kdump
>> cores, I took some time and wrote a small tool to do just that:
>>   http://jeanmarc.saffroy.free.fr/kdump2gdb/
>>
>> The main limitation is that there is absolutely no backtrace of
>> non-running tasks yet, but I will try to see how it can be done. Also, it
>> works only on x86-64, but people are welcome to contribute ports. :)
>
> Hi Jean,
>
> Interesting stuff. Documentation/kdump/gdbmacros.txt already seems to
> be containing various macros for seeing the back traces of non-running
> threads. Won't these help?

Not quite, they need an update for 2.6.18:

(gdb) source kernel/linux-2.6.18/Documentation/kdump/gdbmacros.txt
(gdb) btt
There is no member named pid_list.

BTW I think these macro could use the $task->thread_group list to find 
threads in a process (at least it seems to work for my own "ps" macro).

Anyway, genuine gdb backtraces would be worlds better, so I'll take some 
time to see how to add it. Given a proper thread context, gdb can display 
function params and locals in each frame (if they are not optimized out).

The macros you mention remain useful in adverse conditions (I used similar 
tricks in the past, with lcrash), but I suspect that on average gdb will 
do its job as expected.


Cheers,

-- 
saffroy@gmail.com