[Crash-utility] Why are there two ways of getting register values for active tasks?

Daisuke HATAYAMA d.hatayama at jp.fujitsu.com
Fri May 21 02:07:34 UTC 2010


Hi Dave.

Sorry for the late response.

From: Dave Anderson <anderson at redhat.com>
> 
> ----- "Dave Anderson" <anderson at redhat.com> wrote:
> 
>> ----- "Daisuke HATAYAMA" <d.hatayama at jp.fujitsu.com> wrote:
>> 
>> > Hi, all.
>> > 
>> > I have a question on the implementation of
>> get_netdump_regs_x86_64().
>> > 
>> > Currently, in order to get register values for active tasks, only
>> > panic task makes use of note information. On the other hand, other
>> > active tasks search stack frame for registers saved at nmi
>> > switch. However, crash dump contains the note information for every
>> > CPUs, so I think it uncessary to search stack frame.
>> 
>> Originally it was done that way because the code was written for 
>> netdump-generated dumpfiles, which only generated note information
>> for the panic task.  But if I'm not mistaken, given that recent
>> kernels do not store debuginfo data for the user_regs_struct, it
>> almost always falls through into x86_64_get_stack_frame(). 
> 
> I take that back -- when it's not in the debuginfo, it hardwires
> the user_regs_struct data structure information.
> 
> That being the case, I don't remember why it is restricted to the
> panic task, but it had to have been put in place based upon actual
> dumpfiles where it didn't work correctly for a non-panic task.   
> If I get the time, I'll remove the restriction and run it on
> my set of stashed dumpfile examples to see if I can be more
> specific.

Well, I have still a question: Does kdump-compressed format contain
register values for CPUs?

I've looked into part of makedumpfile reading ELF but found out that
yet. It appears to me that makedumpfile ignores all note info except
for vmcoreinfo's location.

> 
> Anyway, good question -- sorry for such a weak answer...

That's what I needed. Thanks a lot.

Thanks.
HATAYAMA, Daisuke




More information about the Crash-utility mailing list