[Crash-utility] Re: backtrace - how do I get local and formal parametes - kernel is compiled -O0.
Pete/Piet Delaney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> Got by 1st panic crash, crash seems to be working but
|> I don't feel comfortable as with gdb. I can't see
|> the parameters on the stack as variables as with
|> kgdb nor can I see the local variables on the stack.
|> Seems I should be able to get crash working with
|> gdb so I can see the details that gdb can see.
|>
|> I compiled the kernel -O0 and without the framepointer
|> as it seem crash prefers (rather odd). But want to
|> see the locals and formals on the stack and walk up and
|> down the stack and have the context know to crash just
|> as with gdb.
|>
|> I'll re-read your crash paper.
|>
|> Any suggestions?
|
| Nope, other than using "bt -f" to dump each frame's data,
| and figuring it out from there...
When I was using gdb on SunOS 4.1.4 I was able to set $sp and
$fp to switch processes. When I took the SP and FP and used
a gdb set $sp and %fp it didn't seen to allow me to do this:
- -----------------------------------------------------------
crash> gdb set $sp = 0xd76bbbb4
No registers.
crash> gdb set $fp = 0xd76bbc24
No registers.
- -----------------------------------------------------------
Why is is saying 'No registers'?
I'm not positive, but the gdb sources seem to display that message
whenever (!target_has_registers), and that's #define'd like so:
/* Does the target have registers? (Exec files don't.) */
#define target_has_registers \
(current_target.to_has_registers)
And since it's being invoked as "gdb vmlinux", it only knows
about the exec file, and has no clue about registers.
Also why don't you set up gdb with the stack info for the current
task and either allow the user to do a 'gdb bt' or do it with a
crash 'bt' option?
I don't even come close to understanding gdb internals well enough
to know what "set up gdb with the stack info" entails. Send me
a patch when you've got it working -- for all arches, for all tasks,
and without requiring any vmcore file argument... ;-)
Will gdb work directly with the kdump core file? If not when did
it break and why? Docs with 2.6.16 suggest to use gdb of the core
file.
I don't know if it *has* broke...
As I said this morning, I don't know if the latest and greatest 32-bit
gdb can work with 64-bit ELF kdump vmcores, which kdump uses by default
for both 32-bit and 64-bit architectures. The kdump.txt file says this:
* By default, the ELF headers are stored in ELF64 format to support
systems with more than 4GB memory. The --elf32-core-headers option can
be used to force the generation of ELF32 headers. This is necessary
because GDB currently cannot open vmcore files with ELF64 headers on
32-bit systems. ELF32 headers can be used on non-PAE systems (that is,
less than 4GB of memory).
But at least with a 32-bit ELF vmcore, gdb should be able to work.
I recall the crash backtrack proving the gdb info back a few years
ago when I worked on LKCD and crash with you. Is my memory wrong
and this visibility of the formals and local variables has never
never been possible? It's hard to recall for sure with my using
kgdb on the kernel now for so long.
Your memory's wrong, especially w/respect to local variables -- are
you kidding me?
Dave