Folks,
Although we've now fixed one problem (the failure to store %%db6 into
the tss' version of the registers where ptrace could see it), there
remains at least one other problem with the x86 debug register
handling.
Specifically, the code in (arch/i386/kernel/traps.c) do_debug clears
%%db7 if a watchpoint trap is taken in kernel mode. (For instance as
the result of "read" writing over a watched area of store). There is
then _no_ code which restores %%db7 until the task is next
rescheduled. The effect is that all watchpoints in the process are
disabled for (at least) the rest of the process' time-slice if the
interrupted system call does not deschedule the process.
There are two related points here
1) It would be very good to have the data watch triggered from inside
the kernel reported to the user (or more likely the user's
debugger), since if you're trying to find out what is stomping one
of your variables you expect setting a watchpoint on it to tell
you, whether or not the stomping is happening as a result of
passing bad arguments to a system call.
That means that we should be sending the signal, even
if we then zero %%dr7.
2) Whether or not we send the signal, we still need to ensure that the
value of %%dr7 reflects that from the task's tss when we get back
to user code, so that later watchpoint traps are not ignored.
Comments, suggestions ?
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, Inc. +44 117 9071438
http://www.etnus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:21 EST