lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The case for a standard kernel debugger

I am porting the MANOS debugger to Linux. No changes here. Linus will
reject it for the tree, but the offer for SGI and Keith Owens to take it
over and merge it with his kdb effort is also genuine.

:-)

Jeff

Daniel Phillips wrote:
>
> Marco Colombo wrote:
> > BTW, a kernel debugger *is* available. And maybe even a more powerful
> > one will be if Jeff decides to port and publicly release it.
>
> One that subject, I would *love* to take the time to see how small a
> subset of Ext2 I could write to have a (mostly) non-invasive source
> code display.
>
> - No write, no truncate, no remove (i.e., no balloc, no ialloc,
> etc.)
> - No buffering
> - No superblock read: block size always 4K
> - No descriptors, assume inode table blocks always in usual place
> - No dcache: write a simplified directory to a known inode
> - No options
>
> The hardest problem: how do you do the block read? Possibilities:
>
> - Ignore the problem, use normal block device I/O
> - Use the real mode bios, needs V86 support
> - Low level scsi ops with some pre-debugging setup
> - Use a minimal subset of IDE
> - Hacked up protocol over serial port
> - Likewise over ethernet
>
> Doubtless there are many other ways to do it with varying degrees of
> difficulty, intrusiveness, performance and system-dependence. Of
> these techniques the one I personally know best is the V86 approach,
> having written a Dos extender in the distant past. It wouldn't be as
> hard as a Dos extender but it would still take some effort. I'd guess
> that the minimal IDE subset would be a better approach though, because
> you can ignore all mode switching crap, be able to re-purpose a lot of
> existing source and end up with a more generic result.
>
> No matter how you do it there will some impact on system behavior
> somewhere. There always is with any debugger and this has never
> stopped people from using them. First, you start with a horribly
> intrusive debugger then you gradually make it better.
>
> --
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.050 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site