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

-----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'? 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? 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 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. - -piet | | Dave | |