From owner-freebsd-hackers  Sun May  4 14:15:56 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id OAA17664
          for hackers-outgoing; Sun, 4 May 1997 14:15:56 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA17659
          for <hackers@FreeBSD.ORG>; Sun, 4 May 1997 14:15:53 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id HAA26318; Mon, 5 May 1997 07:13:06 +1000
Date: Mon, 5 May 1997 07:13:06 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199705042113.HAA26318@godzilla.zeta.org.au>
To: hackers@FreeBSD.ORG, jhay@zibbi.mikom.csir.co.za
Subject: Re: help needed with kernel debuging and gdb
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>I'm getting a kernel panic with my latest ipx changes (the struct proc *
>thingies). It panic trying to execute at address 0. I can't get gdb to
>show me which function is doing that. The backtrace don't want to go
>past trap(). I have tried setting the frame like in the example in
>the handbook, but it does not seem to work. Is there someone that can
>tell me how?

If address 0 is called, then there should be a trap immediately and the
return address should by at the base of the stack.  Print the value at
$esp and disassemble from there (p/x *(int *)$esp ...).  [gdb seems to
be challenged by expressions in `disass' commands.  ddb handles this
better (x/ia *$esp).]

If address 0 is jumped to, then the function that jumped won't be
directly available.  The frame will contain the return address for this
function and disassembling and/or [pseudo-]executing the code just before
this address will show the function that jumped provided indirect call
addresses haven't changed.

>======
>Fatal trap 12: page fault while in kernel mode
>fault virtual address   = 0x0
>fault code              = supervisor read, page not present
>instruction pointer     = 0x8:0x0
>stack pointer           = 0x10:0xf34a2ec4
>frame pointer           = 0x10:0xf34a2f18
>code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, def32 1, gran 1
>processor eflags        = interrupt enabled, resume, IOPL = 0
>current process         = 156 (IPXrouted)
>interrupt mask          = 
>trap number             = 12
>panic: page fault
>=====

BTW, it's annoying that this long message gets printed before traps
to ddb.  It occurs internally for disassembly at $eip, including for
`sh r' and scrolls the output of `sh r' off the screen, and there is no
scrollback or general more-style paging in ddb.  `sh r' also uses too much
vertical space and would be unusable if there were a few more registers.
Even i386's have more than 25 registers counting the special ones.

Bruce