[Crash-utility] Determining values of arguments and local variable in x86_64 crash dumps

[James Washer]

Very thorough answer, thank you Dave.

I know painfully little about elf debug info.. but perhaps I need to
learn.

Thanks..

 - jim
On Tue, 2008-07-08 at 13:50 -0400, Dave Anderson wrote:
> James Washer wrote:
> > I've always determined the values of locals and parameters/arguments the
> > hard way, i.e. by looking at the disassembly and determining where the
> > values are stored, etc.
> > 
> > I do note however that gdb is pretty damned good at "reading" variables
> > for user programs, which prompts me to ask.. why cannot we do this in
> > crash? (Perhaps we can and I'm just missing something)
> > 
> > Assuming that crash cannot locate locals/args, is there any chance crash
> > might (someday) determine where a register is spilled higher up the
> > stack frame?
> > 
> > Yes, I realize this is all wishlist stuff.. but it cannot hurt to ask
> > (can it?)
> > 
> >  - jim
> 
> It cannot hurt to ask...
> 
> And this question has been raised many times over the years.
> 
> You can use gdb on kdumps, as kdump was designed to work with it
> (although gdb won't work on i386 vmcores when the default
> 64-bit ELF format is used).  And it will give you a backtrace,
> at least until it bumps into the first in-kernel exception
> frame, a stack entity which gdb doesn't have a clue about.
> (although that supposedly wouldn't be a major obstacle, but would
> require tinkering with gdb internals.)  And unfortunately the most
> interesting part of the backtrace is on the other side of the
> exception frame.
> 
> A couple of years ago there was a period of time when unwind
> information was compiled into the kernel for x86 and x86_64,
> and the IBM LTC folks were working on both crash's internal gdb
> code, and subsequently in crash-code-only (see the remnants
> in the still-existing unwind_x86_32_64.c file), but then
> the unwind code was subsequently pulled out of the upstream
> kernel.  Having that in place would make the chore somewhat
> doable, although the primary task at the time was to be
> able to get rock-solid backtraces.  (You have to learn
> to walk first, making the accessing of local variables a
> secondary task...)
> 
> And if IUIC, it would only work for the panic task, or
> active tasks with register dumps in the ELF header, because
> gdb expects a full register set as a starting point.  So
> the non-ELF dumpfile formats, or non-active tasks that only
> have a limited register set stored (where the others are
> pushed onto various upper level stack frames), etc.
> There are several other issues that I can't remember now,
> but it's a task that's easy to ask for but a monster to
> implement.
> 
> That all being said, I welcome any and all attempts...
> 
> Dave
> 
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>