Re: [Crash-utility] Re: backtrace - how do I get local and formal parametes - kernel is compiled -O0.
Pete/Piet Delaney wrote:
I'd like to see a consistent debugging environment from live debugging
with kgdb over to crash analysis with gdb+ddd and crash. Likely the more
crash is integrated into gdb the better. Perhaps over the long term
integrating support into the kernel and gdb would be better. Remember
the old -k option for dbx that Sun used when using dbxtool on the old
M68000 kernels prior to SPARC?
No.
What's the downside to providing the vmcore file to gdb when you
start it and then using the internal command line interface to
set thing like $sp and $fp to get gdb to do it's thing during a
backtrace? Maybe I can get gdb on core files to allow me to
change $sp and $fp with a minor gdb change. If that works I
would think it easy to get crash to do the same to it's gdb
pipe and if you provide the core to gdb on startup. Once gdb
has the stack context, like gdb on old SunOS 4.1.4, then crash
can pass thru cmds to walk up and down the stack.
ELF vmcores are only one of several dumpfile formats crash supports.
With the ever-increasing memory sizes, the use of the post crash
dump makedumpfile utility to change the kdump ELF file into a
compressed diskdump-clone dumpfile format will become all the more
common. Not to mention the use of compressed diskump dumpfiles,
the unique format used by xen dom0 kdump dumpfiles, or the format
used by xen domU dumpfiles, or LKCD, and so on. Any change is
is going to have to be able to extract the information needed
by gdb without having to pass the vmcore file to it. AFAICT
gdb pulls whatever info into needs from the NT_PRSTATUS note
in the ELF header.
Am I dreaming? It tried just changing a global variable in the
core file, starting ddd --write and it core dumped when I changed
the global variable.
That's great -- so just use it and be happy.
And when you have a fully-functional patch that covers all bases,
please post it for review.
Dave