[lldb-dev] Question about breakpoint hit counts

[Zachary Turner]

Thanks, your explanation makes perfect sense.  I'm still a little confused
about the purpose of the 3 argument constructor though.  Can you come up
with a concrete situation where we should use that constructor?  If we use
it with should_stop=true, then the initial hit count will be 0, even though
we've told it that it should stop.  Is this behavior correct?

On Wed Jan 14 2015 at 2:25:36 PM <jingham at apple.com> wrote:

> Just to be clear, the execution control machinery's handling of a thread
> that stops on a breakpoint does not rely on that thread's stop info to
> figure out how to restart the thread.  It can't do that, since the user
> could have put a breakpoint on the PC that the thread happened to be
> stopped at AFTER it stopped.  So the StopInfo's in this case can be used
> freely to create the illusion we want to give the user.
>
> Jim
>
> > On Jan 14, 2015, at 2:14 PM, jingham at apple.com wrote:
> >
> >
> > If a thread hits a thread specific breakpoint that is not for that
> thread, you want that thread to say it stopped for no reason, not that it
> stopped for a reason that isn't actually going to cause it to stop.  For
> instance, suppose I had a thread specific breakpoint set on thread A, and
> both Thread A and Thread B hit that breakpoint.  It would be confusing if
> the stop reason for B was that breakpoint, since the breakpoint was not for
> that thread. The fact that it happens to be sitting on the breakpoint is
> irrelevant to the user.
> >
> > And it would similarly be confusing to say that because the breakpoint
> was for that thread, you knew that the breakpoint was actually going to
> stop.  Many other things could cause it not to stop.
> >
> > The right thing to do is: if the breakpoint is for this thread, create a
> breakpoint stop info with no opinion about should_stop, and if not, create
> an empty stop info.
> >
> > Both ProcessGDBRemote.cpp and StopInfoMachException.cpp do it this way.
> >
> > For some reason, PosixThreads.cpp does the right thing if the breakpoint
> is for that thread - creates one with no opinion about the should_stop if
> it IS for the thread, but if it isn't for that thread it creates a stop
> info with should stop set to false.  That latter bit seems wrong to me for
> the reason given in the first PP.  The commit that added the should_stop =
> false breakpoint for a not-for-this-breakpoint thread doesn't say why it
> was done that way, and Matt isn't working on lldb anymore so he probably
> doesn't remember...
> >
> > Somebody adventurous on the Linux side might want to try getting
> PosixThreads.cpp to do it the way the other code does, and see if that
> causes any fallout.
> >
> > On the Windows side, you should do it the way ProcessGDBRemote.cpp does
> it.
> >
> > Jim
> >
> >
> >> On Jan 14, 2015, at 1:28 PM, Zachary Turner <zturner at google.com> wrote:
> >>
> >> When I hit a breakpoint on Windows, I'm doing something like this:
> >>
> >>        BreakpointSiteSP site(GetBreakpointSiteList().
> FindByAddress(pc));
> >>        lldb::break_id_t break_id = LLDB_INVALID_BREAK_ID;
> >>        bool should_stop = true;
> >>        if (site)
> >>        {
> >>            should_stop = site->ValidForThisThread(stop_thread.get());
> >>            break_id = site->GetID();
> >>        }
> >>
> >>        stop_info = StopInfo::CreateStopReasonWithBreakpointSiteID(*stop_thread,
> break_id, should_stop);
> >>        stop_thread->SetStopInfo(stop_info);
> >>
> >> When should_stop is true (which for now is basically always), this
> results in the breakpoint's hit count not increasing.  It seems this is
> because specifying a value for should_stop leads to m_should_stop_is_valid
> being initialized to true.  But in StopInfoBreakpoint::ShouldStopSynchronous(),
> we only bump the hit count if m_should_stop_is_valid is false.
> >>
> >> I can fix this bug by using
> >>
> >> StopInfo::CreateStopReasonWithBreakpointSiteID(*stop_thread, break_id);
> >>
> >> instead, and since m_stop_info_is_valid is false, and it bumps the hit
> count later.  But I'm not sure if this is the right thing to do, or if the
> behavior I'm seeing with specifying a value for should_stop on creation and
> the hit count not going up is a bug.
> >>
> >> Can anyone explain this?
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150114/9d87f8df/attachment.html>