Variable locations in a loaded kernel (bsd.gdb)

Variable locations in a loaded kernel (bsd.gdb)

[Joshua Lamorie]

Gidday there,

	I'm trying to find how a specific variable is referenced in an
OpenBSD 2.8 kernel.  I build a kernel with symbols, and load it into gdb,
however I can't find a way to see where a specific variable is stored
(stack, memory, register etc...).  I can't run the kernel, and when I type
'p function::variable' it responds with...

No frame is currently executing in block scpshc_decompress.

	Once I have the offset, or address or whatever about the variable,
then I can examine its value in 'ddb' after the kernel crashes.

	Thanks in advance.  I'm running GDB 4.16.1.  The 'configure'
script doesn't let me compile version 5 on OBSD2.8.

Joshua

-- 
Joshua Lamorie                           ph. 514-848-9640
Designer, Space Systems                  fx. 514-848-9644
Xiphos Technologies Inc.                 web http://www.xiphos.ca/

Re: Variable locations in a loaded kernel (bsd.gdb)

[Eli Zaretskii]

On Mon, 27 Aug 2001, Joshua Lamorie wrote:

> 	I'm trying to find how a specific variable is referenced in an
> OpenBSD 2.8 kernel.  I build a kernel with symbols, and load it into gdb,
> however I can't find a way to see where a specific variable is stored
> (stack, memory, register etc...).  I can't run the kernel, and when I type
> 'p function::variable' it responds with...
> 
> No frame is currently executing in block scpshc_decompress.

Does the command "info address" help?

Re: Variable locations in a loaded kernel (bsd.gdb)

[Joshua Lamorie]

On Mon, 27 Aug 2001, Eli Zaretskii wrote:
> Does the command "info address" help?

(gdb) info address scpshc_decompress::tp
No symbol "scpshc_decompress::tp" in current context.
(gdb) 

My problem is that I would like to know what address is being used to
refer to the variable.  Or, if it is in the register, which register.  Or
perhaps a stack offset.. though of course, that is context specific.  At
least, I want to see where it is first referenced, then I can trace it
through the assembler code.

Any hints are appreciated, and I'm playing around with all manner of ways
of viewing.  I can't seem to get a kernel to dump, and when I run 'target
kcore /dev/mem' I get...

(gdb) target kcore /dev/mem
can not access 0xc95e5bee, kvm_read: Bad address
can not access 0xc95e5bee, kvm_read: Bad address
can not access 0xe9eeda89, kvm_read: Bad address
can not access 0xe9eeda89, kvm_read: Bad address
cannot read pcb at 0xe9eeda89

I'll have to start firing off messages to the OpenBSD lists to figure out
more info for using 'ddb'.  I'm amazed, I've just loaded a 26Meg kernel!!

... and it runs! :-)

thanks in advance


-- 
Joshua Lamorie                           ph. 514-848-9640
Designer, Space Systems                  fx. 514-848-9644
Xiphos Technologies Inc.                 web http://www.xiphos.ca/

Re: Variable locations in a loaded kernel (bsd.gdb)

[Andrew Cagney]

> Gidday there,
> 
> 	I'm trying to find how a specific variable is referenced in an
> OpenBSD 2.8 kernel.  I build a kernel with symbols, and load it into gdb,
> however I can't find a way to see where a specific variable is stored
> (stack, memory, register etc...).  I can't run the kernel, and when I type
> 'p function::variable' it responds with...
> 
> No frame is currently executing in block scpshc_decompress.
> 
> 	Once I have the offset, or address or whatever about the variable,
> then I can examine its value in 'ddb' after the kernel crashes.
> 
> 	Thanks in advance.  I'm running GDB 4.16.1.  The 'configure'
> script doesn't let me compile version 5 on OBSD2.8.

Outch! They are both really old GDBs. Could I sugest downloading 
someting more recent? The snapshots are tracking the unreleased 5.1 branch:

	http://sources.redhat.com/gdb/download

Hopefully that at least builds (Changes to get GDB working on the 
various BSD OSs were only committed after GDB 5 was released).

Having done this, I would add a note of caution.  4.16.1 as a GDB 
version number makes me suspicious - afaik it doesn't exist!  I suspect 
it is in fact 4.16ob1 - an OpenBSD specific branch of GDB - and may 
contain features never contributed to the FSF.

	Andrew