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?<br><br><div class="gmail_quote">On Wed Jan 14 2015 at 2:25:36 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Jim<br>
<br>
> On Jan 14, 2015, at 2:14 PM, <a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a> wrote:<br>
><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Both ProcessGDBRemote.cpp and StopInfoMachException.cpp do it this way.<br>
><br>
> 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...<br>
><br>
> 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.<br>
><br>
> On the Windows side, you should do it the way ProcessGDBRemote.cpp does it.<br>
><br>
> Jim<br>
><br>
><br>
>> On Jan 14, 2015, at 1:28 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>><br>
>> When I hit a breakpoint on Windows, I'm doing something like this:<br>
>><br>
>> BreakpointSiteSP site(GetBreakpointSiteList().<u></u>FindByAddress(pc));<br>
>> lldb::break_id_t break_id = LLDB_INVALID_BREAK_ID;<br>
>> bool should_stop = true;<br>
>> if (site)<br>
>> {<br>
>> should_stop = site->ValidForThisThread(stop_<u></u>thread.get());<br>
>> break_id = site->GetID();<br>
>> }<br>
>><br>
>> stop_info = StopInfo::<u></u>CreateStopReasonWithBreakpoint<u></u>SiteID(*stop_thread, break_id, should_stop);<br>
>> stop_thread->SetStopInfo(stop_<u></u>info);<br>
>><br>
>> 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::<u></u>ShouldStopSynchronous(), we only bump the hit count if m_should_stop_is_valid is false.<br>
>><br>
>> I can fix this bug by using<br>
>><br>
>> StopInfo::<u></u>CreateStopReasonWithBreakpoint<u></u>SiteID(*stop_thread, break_id);<br>
>><br>
>> 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.<br>
>><br>
>> Can anyone explain this?<br>
>> ______________________________<u></u>_________________<br>
>> lldb-dev mailing list<br>
>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
><br>
<br>
</blockquote></div>