From: Valdis.Kletnieks@vt.edu
To: Dragoslav Zaric <dragoslav.zaric.kd@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Debug only with printk ?
Date: Tue, 28 Apr 2009 23:15:35 -0400 [thread overview]
Message-ID: <81278.1240974935@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Tue, 28 Apr 2009 23:27:42 +0200." <2d05c4580904281427r65282bb2m5dd8c9f8a2de5363@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]
On Tue, 28 Apr 2009 23:27:42 +0200, Dragoslav Zaric said:
> I am relatively new in linux kernel and since debugging is key
> element of programming, I am wondering is it really necessary
> to use various debugging tools for kernel debugging ?
'git bisect' and friends are your friends if you're trying to track down
a bug in somebody else's code.
It's not *mandatory* to use other tools, but it certainly helps.
> Is simple printing with printk enough to debug any kind of kernel problem,
> and if not, what are the cases when printk is not enough ?
Usually, printk's are sufficient *if* you can use them. Times when this
may not be true:
1) Debugging an early-boot crash, before even the earlyprintk stuff is alive.
2) "Add a printk, recompile, reboot" gets pretty boring pretty fast, so
it may be a *lot* faster if you can use one of the kernel debugging/tracing
tools to do "Well, maybe we should check this... or this.. or wait, how
about *this*?" testing.
3) If you're trying to debug an issue on a production server, you may not
have the *option* to do a lot of compile/reboot cycles, and be forced to
use whatever debug/trace support is present in the already-running kernel.
> Also, is there possibility when using debugging tools to affect
> kernel environment, because debugging tool will also take cpu time and
> memory resources ?
If I had a <monetary unit> for every time when even adding a printk call
was enough to change the timing and cause a Heisenbug to change its behavior,
I'd have a lot of monetary units.
Yes, debugging tools and printks will change code and data offsets and timing
so data overlays and race conditions change or even dissapear/reappear.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
next prev parent reply other threads:[~2009-04-29 3:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-28 21:27 Dragoslav Zaric
2009-04-29 3:15 ` Valdis.Kletnieks [this message]
2009-04-29 17:15 ` Lennart Sorensen
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=81278.1240974935@turing-police.cc.vt.edu \
--to=valdis.kletnieks@vt.edu \
--cc=dragoslav.zaric.kd@gmail.com \
--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
all inboxes | Powered by JetHome®