Re: Dump of trap state

To: Ravi Chamarty <ravi@ittc.ukans.edu>
Subject: Re: Dump of trap state
From: Patrick Tullmann <tullmann@cs.utah.edu>
Date: Tue, 17 Apr 2001 09:40:26 -0600
Cc: oskit-users@fast.cs.utah.edu
In-Reply-To: <Pine.LNX.4.10.10104171001090.4293-100000@elroy.ittc.ukans.edu>; from ravi@ittc.ukans.edu on Tue, Apr 17, 2001 at 10:06:01AM -0500
Mail-Followup-To: Patrick Tullmann <tullmann@cs.utah.edu>, Ravi Chamarty <ravi@ittc.ukans.edu>, oskit-users@fast.cs.utah.edu
References: <Pine.LNX.4.10.10104171001090.4293-100000@elroy.ittc.ukans.edu>
Sender: owner-oskit-users@fast.cs.utah.edu
User-Agent: Mutt/1.2.5i

Ravi Chamarty wrote:

>  If i compile the kernel with debugging support, should I run GDB and
> symtrace on Linux to help me generate call-trace? Also, should I run the
> symtrace on the executable or on the actual multiboot kernel?

First, look at the remote debugging with GDB chapter of the
OSKit documentation:
	http://www.cs.utah.edu/flux/oskit/html/oskit-wwwch15.html#x24-167400015.17
Basically, you can use GDB to attach (via a serial connection) to
your remote kernel and debug it as usual with GDB.

As for symtrace, it is only good for post-mortems.  You should provide
the executable and not the multiboot image to symtrace.  The input to
symtrace is the output of the call stacks (the list of hex numbers)
for each thread.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
       It said "Windows 95 or better" so FreeBSD should run it.

References:

Dump of trap state

From: Ravi Chamarty <ravi@ittc.ukans.edu>

Prev: Dump of trap state
Next: gprof problem
Index(es):
- Main
- Thread