Re: [RFC] New threadnum command for breakpoints

[Frederic RISS <frederic.riss@st.com>]

On Fri, 2006-07-28 at 10:13 -0400, Daniel Jacobowitz wrote:
> On Fri, Jul 28, 2006 at 03:38:41PM +0200, Frederic RISS wrote:
> > Maybe the alternate approach of adding a $thread variable to use in bp
> > conditions ( http://www.sourceware.org/ml/gdb/2006-02/msg00017.html )
> > should be implemented instead ?
> 
> I think that's a better idea.  Although, Vlad used interior_ptid.pid;
> I would have thought that the better choice would be to use GDB's
> internal thread numbering.  (In fact .pid wouldn't even work, that can
> be the same between threads).

Yes. Moreover the user has always access to GDB thread ids (info
threads), but access to other process/thread information isn't enforced
by our target_ops.

I'm all in favor of this idea (mainly because it allows to test for
multiple threads for the same breakpoint), but I think it might be an
issue in some cases:
 * infrun.c detects breakpoint thread mismatch early and has code to
handle thread hops correctly. This code won't be used in case the thread
mismatch is detected only in the breakpoint condition. Couldn't that
cause some problems? (If it's not an issue, we could certainly cleanup
handle_inferior_event to remove that code)
 * I'm also a bit concerned about performance. Evaluating expressions is
heavier that just comparing thread ids. At least in the context I use
this functionality, the faster we resume, the better my system behaves.
I haven't done any real profiling on this this point might be moot. 

Fred.