On Thu, 19 Feb 2004 03:15:54 +0100, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: >How scriptable is kdb? Looking at the docs and google did not really help >me find an answer, but feel free to point me to some docs I overlooked.
Not at all. You can define your own commands using defcmd in kdb/kdb_cmds but those commands are not interactive, nor can they test conditions. >What I want is the ability to log all accesses to a certain memory area >from inside the kernel. AFAICS, breakpoints will not help me here because >there are too few of them available (hardware limitation on i386). >So I thought I could just unmap the page with the problematic memory area >in it and catch all faults accessing this area with kdb, map the area >again, execute the tripping instruction, unmap the area again and continue >execution. > >I suspect a certain driver accessing the mmapped config space of a device >it should leave alone. Unfortunately, reading from there can have side >effects, otherwise I could have just made the covering page readonly. > >Is this possible with kdb or can I at least extend kdb in some way to >achieve my goal? kdb stops all cpus every time it is invoked, which is required for debugging but is far too heavyweight to do for each page fault. How often is the suspect driver believed to be accessing the config space? How often does legitimate code access that config space? --------------------------- Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
