> > This does not happen in reality. Breakpoints can only be set by the
Do you just mean a register_hw_breakpoint call made on current? That
certainly ought to work. That's still "the debugger", i.e. in utracespeak
the tracing engine. My point was that there will never be a facility
intended for a program to use hw_breakpoint to generate a signal that gets
delivered to a handler in the vanilla way. There's always some "outside"
agent who asked for the breakpoint and who is responsible for responding to
the traps it causes, never the program itself so as it would make sense for
it to actually see the signal in the end.
The code in bp_show is exactly the kind of wrong I want to prevent. When I
say they are machine-specific and implementation-specific, I mean there is
no specified part of the interface to which you can presume they correspond
directly. The powerpc implementation will not have any field that is set
to HW_BREAKPOINT_LEN_8 and may well have none set to the type macros
either. If you want to have some machine-specific macros or inlines to
yield the HW_BREAKPOINT_* values for a struct hw_breakpoint, then fine.
Agreed.
Ok. We were both going on what the manual said and I was assuming that
some chip had actually behaved that way and thus that's what users expect.
Ok. This behavior is invisible anyway.
Ok. That is not really surprising.
Ok. This makes the users' expectations make sense. Maybe we can get the
Intel and AMD people to change the manual not to be misleading about this
(it says something terse about "never clears" and without more details I
read it as "never clears any bit, ever").
What about DR_STEP? i.e., if DR_STEP was set from a single-step and then
there was a DR_TRAPn debug exception, is DR_STEP still set? If DR_TRAPn
was set and then you single-step, is DR_TRAPn cleared?
Yowza. That is really surprising.
Agreed. I suspect clearing it to zero is the right thing (given what the
hardware manuals say), even if it appears that DR_STEP and DR_TRAPn do
reset each other on the chips we have on hand.
Thanks.
I think you should post that little patch (and equivalent for x86_64) by
itself. There's no reason that shouldn't go right in.
There is no black magic about that, it's just saying that seqlock/seqcount
does not do any implicit synchronization with your data structure
management. If the pointers in question are protected by RCU, there is no
problem (if your read_seqcount_retry loop is inside rcu_read_lock). Since
the caller supplies the pointers, not requiring them to be freed by RCU
would be simplest for callers. So what seems natural to me is to have a
simple unsigned long kdr[4] array that's updated by register/unregister
calls (while they hold the mutex to exclude each other).
Ok. I thought we were talking about using seqlock to safely read from a
single global data set that's updated in place. I can't really see why
anything but bp_task actually needs to be per-cpu.
The natural thing to me would be to just use the same seqcount-based update
style from a global kdr[4] here.
Call it a generic "make it go after setting each debug register".
For most other machines this will be a no-op.
This is probably always < TASK_SIZE_OF (or TASK_SIZE #ifndef),
but it is probably right to make it an arch macro.
Ha. Probably noone else has that arcane bit of compatibility to do, in fact.
Right. There is nothing in common about this except for needing something
(so maybe an arch-defined struct inside the struct thread_hw_breakpoint).
It does.
I am no authority on kconfig, so seek other advice.
What kprobes does is a separate "config KPROBES" in each arch/foo/Kconfig.
This means that the details and help text must be given separately for each
one. This is a bug or a feature, depending on whether you dislike
repeating the same help text in several places and having it drift and not
stay uniformly maintained, or you want to include different arch-specific
details in the text.
The other option I see is one central:
config HW_BREAKPOINT
depends on X86 || X86_64 || ...
...
AIUI, with this, arch/foo/Kconfig can still have just the lines:
config HW_BREAKPOINT
depends on !FOOBAR
when the FOOBAR submodel of the foo arch does not have the hardware
support, or for whatever reason an arch adds more constraints to the
generically-defined config option.
The latter one is what I would do, but I might get corrected if I did.
Thanks,
Roland
-
