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