Messages in this thread | | | Date | Fri, 6 Jul 2007 16:48:59 -0400 (EDT) | From | Alan Stern <> | Subject | Re: [RFC] hwbkpt: Hardware breakpoints (was Kwatch) |
| |
On Wed, 27 Jun 2007, Roland McGrath wrote:
> In the first battle just to make it compile, the only issue was that you > assume every machine has TIF_DEBUG, which is in fact an implementation > detail chosen lately by i386 and x86_64. AFAIK the only reason for it > there is just to make a cheap test of multiple bits in the hot path > deciding to call __switch_to_xtra. Do you rely on it meaning something > more precise than just being a shorthand for hw_breakpoint_info!=NULL?
Going over the code, I remembered that TIF_DEBUG really does mean moree than just hw_breakpoint_info != NULL. It means that the thread actually has some breakpoints registered.
Why keep the hw_breakpoint_info structure if there are no registered breakpoints? I did it so that the virtualized DR[0-3] values would remain intact.
For other processors that have only one debug register, this won't matter so much. But of course there are references to TIF_DEBUG in the arch-independent code. Do you think there would be any problem about reserving a bit for TIF_DEBUG in the other architectures?
Alan Stern
P.S.: I'm just now getting around to doing the stuff we discussed last week. It has been a busy time... At OLS somebody asked when hw-breakpoint would get into the mainline. I guessed that it would be a few months before it is added to -mm. Solving this pre/post-notification issue will be difficult.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |