> Yes, you are wrong -- although perhaps you shouldn't be.
Ah, I see. I think it would indeed be nice to fix this.
The user blocking or ignoring it doesn't come up, because it's a
force_sig_info call. However, a debugger will indeed swallow the signal
through ptrace/utrace means. In ptrace, the dr7 is always going to get
reset because there will always be a context switch out and back in that
does it. But with utrace it's now possible to swallow the signal and keep
going without a context switch (e.g. a breakpoint that is just doing
logging but not stopping). So perhaps we should have a TIF_RESTORE_DR7
that goes into _TIF_WORK_MASK and gets handled in do_notify_resume
(or maybe it's TIF_HWBKPT).
You should not actually need to disable user watchpoints, because in data
watchpoints the exception comes after the instruction completes. Only for
instruction watchpoints does the exception come before the instruction
executes, and no user watchpoints can be in the address range containing
kernel code.
SIGTRAP both doesn't queue, and doesn't give %dr6 values in its siginfo_t.
All user watchpoints will be handled via the signal; this is the only way
ptrace can report them, and is also the utrace way of doing things.
do_debug can happen inside kernel code, and tracing of user-level tasks can
only safely do anything at the point just before returning to user mode,
where signals are handled. So, getting to send_sigtrap in do_debug is
enough to say "one or more user debug exceptions happened". The %dr6 value
that collects in the thread state to be seen by ptrace, or by utrace-based
things using your new facility, needs to collect all the %dr6 bits that
were set by the hardware and weren't consumed by kernel-level tracing. An
eventual utrace-based thing might in fact have some other way to tie in so
that the event details could just be in some call made by do_debug and not
recorded in the thread's virtual %dr6 value. But at least for ptrace, they
should collect there if it becomes possible for more than one exception to
happen while in kernel mode or in a single user instruction. (A single
instruction can cause multiple exceptions at the hardware level.)
That sounds great. I'm not thrilled with the name "debugpoint", I have to
tell you. The hardware documentation calls all these things "breakpoints",
and I think "data breakpoint" and "instruction breakpoint" are pretty good
terms. How about "hwbkpt" for the facility API?
I think that's a fine idea.
The one caveat I have here is that I don't want ptrace (via utrace) to have
to supply the usual structure. I probably only think this because it would
be a pain for the ptrace/utrace implementation to find a place to stick it.
But I have a rationalization. The old ptrace interface, and the
utrace_regset for debugregs, is not really a "debugpoint user" in the sense
you're defining it. It's an access to the "raw" debugregs as part of the
thread's virtual CPU context. You can use ptrace to set a watchpoint, then
detach ptrace, and the thread will get a SIGTRAP later though there is no
remnant at that point of the debugger interface that made it come about.
For the degenerate case of medium-high priority with no handler callbacks
(that should instead be an error at registration time if no slot is free),
you shouldn't really need any per-caller storage (there can only be one
such caller per slot).
I know about kprobes. I don't know about vm86, but I can read the code.
Thanks,
Roland
-
