public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Keith Owens <kaos@ocs.com.au>
Cc: Jeremy Jackson <jerj@coplanar.net>, linux-kernel@vger.kernel.org
Subject: Re: [QUESTION] which kernel debugger is "best"?
Date: Fri, 29 Mar 2002 20:24:05 -0800	[thread overview]
Message-ID: <3CA53DE5.668AC7AB@zip.com.au> (raw)
In-Reply-To: Your message of "Fri, 29 Mar 2002 19:18:39 -0800." <3CA52E8F.C8D0E5F8@zip.com.au> <2178.1017459962@ocs3.intra.ocs.com.au>

Keith Owens wrote:
> 
> On Fri, 29 Mar 2002 19:18:39 -0800,
> Andrew Morton <akpm@zip.com.au> wrote:
> >Jeremy Jackson wrote:
> >>
> >> What are people using?
> >
> >kgdb.  Tried kdb and (sorry, Keith), it's not in the same
> >league.  Not by miles.
> 
> <good points deleted>
> ..
> Pick the right tool.

I guess the distinction here is that I use kgdb for "development",
not for "debugging".

Displaying data structures, values of variables.  Seeing what
state all tasks in the system are in, where they're sleeping,
where they're spending CPU, etc.

When adding ad-hoc inxtrumentation to the kernel, you don't
need to bother printing it out - just increment the counters
and go in take a look when desired.

And yes, kgdb mucks up call chains across down() because of the
lack of a frame pointer - backtraces don't display who called
down() - it loses the innermost frame.  That's irritating,
but not enough to have motivated me to soil my hands with
x86 assembly yet.

I haven't had any problems with -fno-omit-frame-pointer at
any time.

I *have* had problems with -fno-inline.  I'd very much like
to be able to turn that on, but the presence of `extern inline'
functions causes a link failure with `-fno-inline'.  I'd suggest
that this is a gcc shortcoming.  I actually had a poke yesterday
at teaching gcc to convert extern inline to static inline if 
flag_no_inline, but it didn't work out.

kgdb is damned inconvenient.  You have to set up a cross-build
machine, serial cable and generally get organised to use it.
In reality, this would take an hour or so but it is some friction.

I would like to see kdb shipped in the mainline kernel, so that
we can get better diagnostic reports from users/testers.


-

  reply	other threads:[~2002-03-30  4:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-30  2:38 [QUESTION] which kernel debugger is "best"? Jeremy Jackson
2002-03-30  3:18 ` Andrew Morton
2002-03-30  3:46   ` Keith Owens
2002-03-30  4:24     ` Andrew Morton [this message]
2002-03-30  4:25       ` David S. Miller
2002-03-30 15:22       ` Peter Wächtler
2002-04-01  9:20         ` Amit S. Kale
2002-04-01 13:44       ` Philip R. Auld
2002-03-30  4:04 ` Keith Owens

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=3CA53DE5.668AC7AB@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=jerj@coplanar.net \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /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