Re: The case for a standard kernel debugger

• Next message: Theodore Y. Ts'o: "Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee"
• Previous message: Andi Kleen: "Re: The case for a standard kernel debugger"
• In reply to: Andi Kleen: "Re: The case for a standard kernel debugger"
• Next in thread: Jeff V. Merkey: "Re: The case for a standard kernel debugger"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Andi Kleen wrote:
>
> On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> > 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
>
> And it requires a sync before every possible crash to ensure cache
> coherency (assuming you want to access the same ext2 without the debugger
> as well) So you basically cannot buffer writes to that source code.

The rule is: no writing to the source code while you are debugging.
Only write to the source code when you also plan to compile it. You
can unmount your source code partition when you start the debugger.

--
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/

• Next message: Theodore Y. Ts'o: "Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee"
• Previous message: Andi Kleen: "Re: The case for a standard kernel debugger"
• In reply to: Andi Kleen: "Re: The case for a standard kernel debugger"
• Next in thread: Jeff V. Merkey: "Re: The case for a standard kernel debugger"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST