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