[Crash-utility] Re: backtrace - how do I get local and formal parametes - kernel is compiled -O0.

[Dave Anderson]

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