> It seems to me that signal handlers must run with a copy of the original
Of course. I'm talking about how the registers get changed to set up the
signal handler to start running, not how the interrupted registers are
saved on the user stack. There is no issue with the stored eflags image;
the "privileged" flags like RF are ignored by sigreturn anyway.
This does not happen in reality. Breakpoints can only be set by the
debugger, not by the program itself. The debugger should always eat the trap.
Starting a signal handler is "warping the PC" equivalent to changing it via
ptrace for purposes of this discussion. In case the new PC is the site of
another breakpoint, RF must be clear.
AFAICT it never actually uses hardware instruction breakpoints, only data
watchpoints. I wouldn't be surprised if noone has ever really used
instruction breakpoint settings in x86 hardware debug registers on Linux.
(Frankly, I don't much expect them to start either. This level of detail
about instruction breakpoints is largely academic. I am a stickler for
getting the details right if we're going to allow using them at all.
But I think really everyone only cares about data watchpoints.)
That's a red herring. gdb is the compatibility case, not the real API user.
That is fine. If the flutter issue comes up, we can address it later.
I'm moderately sure they do nothing on modern CPUs. Intel says they're
ignored as of Pentium, but recommends setting both bits if you care at all.
In practice, I don't think we'll ever hear about the inexactness on a
pre-Pentium processor from not setting the bits. But I'd follow the Intel
manual and set both.
The earlier quote I gave was from an AMD64 manual. A 1995 Intel manual I
have says, "All Intel Architecture processors manage the RF flag as follows,"
and proceeds to give the "all faults except instruction breakpoint" behavior
I quoted from the AMD manual earlier. Hence I sincerely doubt that this
varies among Intel and AMD processors. Someone else will have to help us
know about other makers' processors. So far I have no reason to suspect that
any processor behaves differently (aside from generic cynicism ;-).
Yes, that is really the kind of thing I had in mind. For user breakpoints it
shouldn't be an issue, since the thread shouldn't have been let run in between.
That is in the "difficult race" category to ensure. I would not presume.
I think that is what I suggested an iteration or two ago. Installing new
state means making a fresh data structure and installing a pointer to it,
leaving the old (immutable) one to be freed by RCU.
I guess my main objection to having .type and .len is the false implied
documentation of their presence and names, leading to people thinking they
can look at those values. In fact, they are machine-specific and
implementation-specific bits of no intrinsic use to anyone else.
If it's actually a flag, then treating it any other way is just confusing.
I can't see how it's easier for anyone.
Then it really is just a flag for all uses, and there's no reason at all to
call it a number.
I think that is going to be the clean and sane approach.
Hand-rolling your low-level synchronization code is always questionable.
That line from the manual is what we were both going on originally, and
then you described the conflicting behavior. I was trying to ascertain
whether chips really do vary, or if the manual was just inaccurate about
the single common way it actually behaves. I take it you have in fact
observed different behaviors on different chips?
There are two possible kinds of "conservative" here. To be conservative
with respect to the existing behavior on a given chip, whatever that may
be, we should never clear %dr6 completely, and instead should always
mirror its bits to vdr7, only mapping the low four bits around to present
the virtualized order. The only bits we'd ever clear in hardware are
those DR_TRAPn bits corresponding to the registers allocated to non-ptrace
uses, and kprobes should clear DR_STEP. And note that when vdr6 is
changed by ptrace, we should reset the hardware %dr6 accordingly, to match
existing kernel behavior should users change debugreg[6] via ptrace.
To be conservative in the sense of reliable user-level behavior despite
chip oddities would be a little different. Firstly, I think we should
mirror all the "extra" bits from hardware to vdr7 blindly, i.e. everything
but DR_STEP and DR_TRAPn. That way if any chip comes along that sets new
bits for new features or whatnot, users can at least see the new hardware
bits via ptrace before hw_breakpoint gets updated to support them more
directly. For the low four bits, I think what users expect is that no
bits are ever implicitly cleared, so they accumulate to say which drN has
hit since the last time ptrace was used to clear vdr6.
There's no reason to waste another word when you only need two bits and
already have spare space for a machine implementation field (i.e. where .type
is now).
Thanks,
Roland
-
