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