Re: [Crash-utility] Determining values of arguments and local variable in x86_64 crash dumps
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