linux-kernel - Re: [git pull] x86 arch updates for v2.6.25

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Feb 2008 20:54:12 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Phil Oester <kernel@...uxace.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 arch updates for v2.6.25

On Mon, 4 Feb 2008 20:11:03 -0800 Phil Oester <kernel@...uxace.com> wrote:

> On Mon, Feb 04, 2008 at 07:27:53PM -0800, Linus Torvalds wrote:
> > kgdb? Not so interesting. We have many more hard problems happening at 
> > user sites, not in developer hands.
> 
> FWIW, I'm not a fulltime developer by any means, but on occasion
> I have fixed a few bugs in the netfilter area of the kernel.
> And in almost all cases, I used kgdb in my debugging and testing

                                                           ^^^^^^^
> of fixes.  

yup.

> In doing so, it was a bit of a PITA to find/patch kgdb into the
> kernel, and having it as a configurable option would have saved
> me some time and effort and made the process much smoother.
> 
> So perhaps someone else out there would find it similarly useful,
> and the extra time it takes to find/patch/compile kgdb in is
> precluding them from participating?  Why would we ever want to do
> that?

I used kgdb continuously for 4-5 years until it broke.  I don't think I
ever used it much for "debugging" as such.  I used it more for general
observation of what's going on in the kernel.  And for _confirmation_ of
what's going on (ie: testing that the actual state matches the expected
state).

I'd end up doing my development with the assumption that kgdb was present. 
One example: rather than putting printks all over the place to ensure that
the right thing was happening at the right time I'd instead add code like

void foo(void)
{
}

	...
	if (expr)
		foo();

then, when the testcase was up and running and in steady state, break in
and put a breakpoint on foo().  Continue, wait for the breakpoint then go
in and observe locals, globals, data structures, etc.

It's hard to describe (and remember!).  But the presence of the debugger as
a development (not debugging) tool changes the way you do development a bit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/