mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: aaronp@regurgitate.ugcs.caltech.edu (Aaron Passey)
To: mlist-linux-kernel@nntp-server.caltech.edu
Subject: Re: Linux Kernel Debuggers, KDB or KGDB?
Date: 1 May 2001 07:13:17 GMT	[thread overview]
Message-ID: <slrn9esogd.i8g.aaronp@regurgitate.ugcs.caltech.edu> (raw)
In-Reply-To: <linux.kernel.18223.988679810@kao2.melbourne.sgi.com>

On Tue, 01 May 2001 11:16:50 +1000, Keith Owens <kaos@ocs.com.au> wrote:
>kgdb relies on gdb so you loose the knowledge of kernel internals (no,
>I am *not* going to teach gdb about kernel stacks, out of line lock
>code etc.).  kgdb has more of a dependency on a working kernel.  It
>provides source level debugging, although stack backtrace tends not to
>work unless you compile the kernel with frame pointers.
>
>UML is great for debugging generic kernel code such as filesystems, but
>cannot be used for most arch code or hardware drivers.
>
>My ideal debugger is one that combines the internal knowledge of kdb
>with the source level debugging of gdb.  I know how to do this over a
>serial line, finding time to write the code is the problem.

I've been thinking about this a little bit and I suspect the right thing
may be to combine a kgdb style debuging stub with the Mission Critical
Linux crash code (http://oss.missioncriticallinux.com/projects/crash/).
Crash is based around gdb and adds the ability to easily examine the
process table, memory maps, kernel logs, wait queues, timers, etc.  Crash
already is able to examine a live system by reading /dev/mem.  The only
thing you'd need to add is the ability to attach to a live system over a
serial port (probably not too hard since gdb already knows how to do that).

Aaron

       reply	other threads:[~2001-05-01  7:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <linux.kernel.18223.988679810@kao2.melbourne.sgi.com>
2001-05-01  7:13 ` Aaron Passey [this message]
2001-04-30 21:17 Paul J Albrecht
2001-05-01  0:11 ` Jeff Dike
2001-05-01  9:37   ` Ingo Oeser
2001-05-01 15:22     ` Jeff Dike
2001-05-02 14:44       ` Ingo Oeser
2001-05-02 17:54         ` Jeff Dike
2001-05-02 16:55           ` Alan Cox
2001-05-02 19:06             ` Jeff Dike
2001-05-02 18:54               ` Bill Nottingham
2001-05-01  1:16 ` Keith Owens
2001-05-01 10:59   ` Amit S. Kale
2001-05-02 14:58   ` Andi Kleen
2001-05-02 21:06   ` Paul J Albrecht
2001-05-02 23:03     ` Keith Owens
2001-05-03 14:46       ` Amit S. Kale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=slrn9esogd.i8g.aaronp@regurgitate.ugcs.caltech.edu \
    --to=aaronp@regurgitate.ugcs.caltech.edu \
    --cc=mlist-linux-kernel@nntp-server.caltech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®