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

[Jim Ingham]

On Sep 10, 2012, at 2:37 PM, Jim Ingham <jingham at apple.com> wrote:

> Matt,
> 
> I think the correct logic here is: "If there is a breakpoint at the PC and the real reason this thread stopped was a breakpoint hit, then step over the breakpoint, otherwise let the program hit the trap." 
> 
> However, I don't think it can be fixed just using stop reasons.  There are a couple of problems:
> 
> 1) The StopInfo's are cleared each time you run.  So if I hit a breakpoint on thread A, then the user switches to thread B and does a simple step (which we will do by only running thread B) then the StopInfo for thread A after the second stop will be "Invalid".  That is convenient, since then you won't keep reporting the first thread as having hit a breakpoint when in fact it didn,t do anything.  But it does mean when you eventually get to run Thread A the stop reason won't be right for these purposes.  
> 
> 2) The user could have hit a breakpoint, then moved the PC to another location that also has a breakpoint at it.  In that case we wouldn't hit the breakpoint at the new location, which would also be wrong.
> 
> I was just trying to be too clever, and thought I could avoid keeping the fact that the thread had hit a particular breakpoint site as a separate bit of information.  But to get this totally right, it seems to me we're going to have to record the fact that the thread stopped for a breakpoint hit and the PC it stopped at.  Then in SetupForResume, if the thread is going to run, check that it stopped for a breakpoint hit, and if we are still at the same PC and there's still a breakpoint at that PC, we push the step over breakpoint plan and clear the "breakpoint site hit by this thread".
> 

Actually, the StopInfo's currently have a StopID, and IsValid checks the StopID to see if it is older than the current stop as well.  So it is possible you could rely on the old stop info.  Note that the stop info's persistence is mostly used for the trickery we play to make sure that calling functions on a thread doesn't upset the stop reason.  I don't think we rely on it for anything else.

If we were going to use it for this purpose, we would have to guarantee that it hangs around till the thread actually gets a chance to run.  The code in ThreadGDBRemote::GetPrivateStopReason that resets it worries me.  But that might be cleaner than adding another piece of data.  Note, if the stop reason is breakpoint, then the site id for the breakpoint hit is the StopInfo's value, so that would tell you whether you were still at the PC of the breakpoint hit.

Jim


> Jim
> 
> 
> On Sep 10, 2012, at 1:58 PM, "Kopec, Matt" <matt.kopec at intel.com> wrote:
> 
>> 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
>> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits