> That should work well. But how does the handler know whether a ptrace
That's what I did in the powerpc code. You might recall I originally
argued for not using a regular hw_breakpoint struct and callback for ptrace
at all. (I still think it could wind up pretty clean and tight to have it
purely a special case using its own data structures without a struct
hw_breakpoint. Only the priority stuff has to do something special to
treat ptrace-in-use as a registration with the right priority.)
When do_debug sets TIF_SINGLESTEP, it will lead to a SIGTRAP on the way
back to user mode. The idea is that it should appear to user mode like the
syscall was any hardware instruction that got the step trap. So it follows
(and matches existing behavior) to set DR_STEP in vdr6 in this case too.
I would not remove TIF_DEBUG where it exists now. It was added on x86 and
x86_64 as an optimization so the common case tests and decides not to call
__switch_to_xtra with one instruction. Don't lose that optimization.
What I meant is using some arch hooks instead of those fields in the
generic code. On machines where there is a count to keep, they would just
be trivial accessors (could be one-line macros). On powerpc, they would be
implemented slightly differently and return 1 or 0.
Right, I wasn't suggesting losing that.
Ah, that's a thought. Ok. I was already tending towards flexibility to
let someone do that if they wanted to (on trigger-before machines).
Yes, I was sort of thinking it up while I typed there.
My rationale is that judiciously rejecting impossible settings in fact
makes it easier to write (correct) portable drivers. If you set a callback
function that will never be called, you are confused and are going to have
the logic go wrong in your code. If you can't get started while under the
delusion that your function is going to be called, then you won't waste all
that time on subtle debugging trying to figure out why it's not getting called.
I don't disagree. But the point is that on ia64 there is a case where no
stepping is required, so there is no reason the arch hooks shouldn't
indicate to users that this usage pattern is available. Also,
realistically the single-step to post-handler part of the implementation
will come last for each arch, and flexible users can do interesting things
with partial support if they have the information on what the
implementation supports.
Ok.
Ok. Whenever all the virtual bits are zero you can free it. That is
probably worth doing for the case when ptrace is never used, but some other
exciting new facility comes in and uses watchpoints for a while and then
goes away.
In my powerpc patch I made those conditional and that seems fine. I think
that having a TIF_DEBUG is an arch-specific choice, and each arch should
decide whether it is advantageous.
Thanks,
Roland
-
