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

[Piet Delaney]

Dave Anderson wrote:
> 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.

Running ddd+gdb on the crash dump seem to be working unreasonably
well. The back traces for the task running on CPU's are available as
well as the registers.

I thought it would be convenient to get the $sp and $fp from 'crash' for a
task that I'm interested in and change the values of $sp and $fp for one
of the CPU's contexts.  I did a 'set write on' to allow me to change the 
contents
of the crash dump but it continues to say the $sp isn't an l-value.

    gdb) set write on
    gdb) set $sp += 4
        Left operand of assignment is not an lvalue.
    (gdb)

 
  (gdb) help set write
     Set writing into executable and core files.
   (gdb)

kgdb use to allow this on live sessions on SunOS 4.1.4.
Seems to a common practice still:

    http://www.mcs.vuw.ac.nz/cgi-bin/info2www?(gdb)Registers

I'm fine on the current bug that I'm looking into but would
like to be able to use gdb on all of the tasks; not just the ones
currently running on CPUs. The kdump gdb macros are a bit
of help but extremely slow. I once looked in kgdb running slow
on gdb macro interpretation and at that time is was a silly lack
of caching that was causing the gdb 'ps' macro to run so slowly.

 
-piet
>