Re: [RFA] thread specific breakpoints and single stepping

[SUZUKI Emi <emi-suzuki@tjsys.co.jp>]

Ping?

Or, should I offer reviews separately, with deleting 
the call of breakpoint_thread_match and calling
single_step_breakpoint_inserted_here_p?

From: Emi SUZUKI <emi-suzuki at tjsys.co.jp>
Subject: Re: [RFA] thread specific breakpoints and single stepping
Date: Fri, 01 Aug 2008 20:58:49 +0900 (JST)

> 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?