kdb
[Top] [All Lists]

Re: KDB enhancements

To: linas@xxxxxxxxxxxxxx
Subject: Re: KDB enhancements
From: Steven Dake <sdake@xxxxxxxxxx>
Date: 18 Jul 2003 17:55:30 -0700
Cc: Keith Owens <kaos@xxxxxxx>, Will Schmidt <willschm@xxxxxxxxxx>, kdb@xxxxxxxxxxx
In-reply-to: <20030718194037.A48774@forte.austin.ibm.com>
Organization: MontaVista Software, Inc.
References: <OFA5785D39.9E649B65-ON86256D67.0055F0E8-86256D67.00568BC4@us.ibm.com> <6217.1058544192@ocs3.intra.ocs.com.au> <20030718194037.A48774@forte.austin.ibm.com>
Reply-to: sdake@xxxxxxxxxx
Sender: kdb-bounce@xxxxxxxxxxx
On Fri, 2003-07-18 at 17:40, linas@xxxxxxxxxxxxxx wrote:
> Hi Keith,
> 
> I'm vaguely daydreaming about a few KDB enhancements, I was curious if 
> you've thought about them:
> 
> -- 'cat /proc/meminfo'  Turns out one bug I was chasing was OOM on
>    a machine with 32GB of RAM (!) and it took me days to even think
>    of looking there.
> 
> -- Support for examining structures symbolically.  I've had to walk
>    the buffer cache by hand in the past, I've walked task struct
>    by hand yesterday, and they guy down the hall stares at network
>    structs.  
> 
While we are dreaming :) complete source level debugging would be very
useful.  I was thinking this would best be done over serial or ethernet
with a kdb engine running in the target kernel.  This would allow a
debugger to use the kdb commands to symbolicly debug a running kernel.

Much better then kgdb, which lacks many of the functionalities required
by a good kernel debugger.

>    I don't know if it would be better to handle a few of these as 
>    special-cases in some simple manner, or if some more complex but
>    generic mechanism would be better ... 
> 
> --linas
> 
> 
> 


<Prev in Thread] Current Thread [Next in Thread>