Hi Daniel, 

thank you for your comment.  

From: Daniel Jacobowitz <drow at false.org>
Subject: Re: [RFA] thread specific breakpoints and single stepping
Date: Fri, 25 Jul 2008 23:01:33 -0400

> On Wed, Jul 09, 2008 at 09:10:38PM +0900, Emi SUZUKI wrote:
> > It works better than mine.  But while I am concerning about
> > single-stepping for software watchpoints, I noticed that we should
> > also check whether a hardware watchpoint is triggered.  
> 
> As this condition gets more complicated, I'm getting worried about
> keeping it in sync with everything else.  Could it be that the logic
> is wrong - we should determine whether a thread hop is necessary later
> in the process?  It should be just like a breakpoint with a false
> condition.

Ah, yes.  I also feel like that I would eventually implement the same
procedures to two different places...

I investigated the condition again, and found that all the need for
thread hopping over a regular breakpoint can determine by calling
bpstat_stop_status as you suggested: even breakpoint_thread_match is
not necessary here.  
So I revised the patch to delete it.  handle_inferior_event was the
last caller of breakpoint_thread_match, but I just left it defined.  

And I found another problem: when a hardware watchpoint trigger
occured while doing software single-stepping, the trigger can be
ignored by a thread hop.  

I think it would be fixed by calling
single_step_breakpoint_inserted_here_p instead of checking
singlestep_breakpoints_inserted_p, to make sure a thread is really
trapped by a software single step breakpoint.  But I don't have a
environment where I can reproduce the situation.  
It may occur on a PPC box...?

And I doubt if the testcases are reasonable now, but at least the
tests fails without a patch, and succeeds with it, on x86-linux-gnu.  

Is that OK?

-- 
Emi SUZUKI / emi-suzuki at tjsys.co.jp