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 -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility