[Lldb-commits] [PATCH][Please review] Check StopInfo instead of pc/breakpointsite to determine if we are at a breakpoint

[Kopec, Matt]

So does it makes sense to push the step over plan under eStopReasonPlanComplete as well in the proposed patch? Are there any other cases?

Thanks,
Matt

-----Original Message-----
From: Jim Ingham [mailto:jingham at apple.com] 
Sent: Monday, September 10, 2012 4:44 PM
To: Kopec, Matt
Cc: lldb-commits at cs.uiuc.edu
Subject: Re: [Lldb-commits] [PATCH][Please review] Check StopInfo instead of pc/breakpointsite to determine if we are at a breakpoint


On Sep 10, 2012, at 1:33 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:

> Problem: If there are breakpoints on consecutive instructions, the debugger doesn't stop on the consecutive breakpoints after the first breakpoint.
>  
> After hitting the first breakpoint and then stepping/continuing, the step over breakpoint plan will be pushed to the plan queue for the next consecutive breakpoint (the first breakpoint has been stepped over and pc incremented). This will cause lldb to step over the next consecutive breakpoint and run without actually stopping on the breakpoint(s).
>  
> On a side note, is there a specific reason for checking the pc/breakpointsite list instead of the stop reason?

Yes, you could have stopped at the current location for some other reason (for instance the completion of a step) and while stopped the user could have inserted a breakpoint at the current PC.  Remember, this code doesn't get run till the debugger is about to continue.  In that scenario, the stop reason would be PlanComplete, but there would still be a breakpoint under the PC that you would need to step over.

Jim

> <consecutive-bp-inst-fix.patch>_______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits