> 
> and since name is a variable local to sys___sysctl() (whose address is
> apparently 0xcfcd8f10), i should be able to find the sys___sysctl()
> stack frame somewhere around 0xcfcd8f10.  let's see...pointer,
> pointer, int, a couple of size_ts, another pointer, an array of ints
> called name (CTL_MAXNAME aka 12 in length), and another
> pointer...that's 19 x 4 (this is i386), so we look at this:
> 
> (gdb) x/48x 0xcfcd8f00
> 0xcfcd8f00:     0xc030cae0      0x00040000      0xcfcc8500      0x00040000
> 0xcfcd8f10:     0x00000001      0x00000030      0x00000277      0x00000001
> 0xcfcd8f20:     0x0000002e      0x00000000      0xcfcd8f68      0xc0b9b000
> 0xcfcd8f30:     0x0180d00a      0x2f83d00a      0x00000000      0x00000004
> 0xcfcd8f40:     0xcfcd8fa0      0xc03a1e3b      0xcfae3688      0xcfcd8f80
> 0xcfcd8f50:     0xcfcd8f78      0xc0ac6340      0xbdbbd2e0      0xbfbfedbc
> 0xcfcd8f60:     0x00000004      0x00000000      0x00000006      0xc043f464
> 0xcfcd8f70:     0xcfcd8fa0      0xc0699fb0      0x00000000      0x00000000
> 0xcfcd8f80:     0xbfbfedbc      0x00000004      0x0807b000      0xbfbfedb8
> 0xcfcd8f90:     0x00000000      0x00000000      0xc0ac8500      0xc0ac8500
> 0xcfcd8fa0:     0xbfbfed5c      0xc0100c6b      0x0000001f      0x0000001f
> 0xcfcd8fb0:     0x0000001f      0x0000001f      0x00000004      0xbfbfedbc
> 
> now...the { 0x1, 0x30, 0x277, 0x1 } is the name array (where the
> initial 0x1 is presumably CTL_KERN).  going back to the ddb stackdump
> that says the fourth argument to sysctl_procargs() was 0xcfcd8f0c,
> that must be the address of sizep (known here as oldlen), the 0x40000
> value.  since i've dumped the vmspaces of all the processes from the
> kernel core, i can say that the ps process was 334 which has a paddr
> (according to ps) of cfcc8500.  that value appears at 0xcfcd8f08 in
> the dump above.  so...where's the thing that i feed to gdb to step to
> that stack frame?

Ok - how to follow the stack by hand...
Each stack frame (on i386) looks like:
	locals
	saved ebp
	return address
	arguments
The ebp values point to each other, so once you've found one frame, you
can sort out the traceback.
The 'trap' frame will be different, I don't know the layout for netbsd.
But the trap itself will push 'flags', cs, eip (ie eip on top of stack).

Now I can't see the ebp chain in the above fragment - but I don't have
the hex return addresses of the known frame to help.

If you dump out a lot more of the stack (above and below) the part shown,
you should be ably to identify the frames for the sysctl sequence
and the part the gdb finds.  The gap in the middle will contain the
registers at the time of the fault!

	David

-- 
David Laight: david@l8s.co.uk