This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] thread specific breakpoints and single stepping
- From: SUZUKI Emi <emi-suzuki at tjsys dot co dot jp>
- To: drow at false dot org
- Cc: pedro at codesourcery dot com, gdb-patches at sourceware dot org
- Date: Tue, 19 Aug 2008 15:09:14 +0900 (JST)
- Subject: Re: [RFA] thread specific breakpoints and single stepping
- References: <20080709.211038.135588294.emi-suzuki@tjsys.co.jp> <20080726030133.GC1895@caradoc.them.org> <20080801.205849.190217198.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?