lkml.org 
[lkml]   [2007]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2007-07-06 22:51    [W:0.021 / U:5.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site