labath added a comment.
The test added by this batch is failing on windows
http://lab.llvm.org:8011/builders/lldb-windows7-android/builds/2499, for a very
prosaic reason - we cannot run a "make clean" as something is holding the
executable file open. Based on my debugging, it is not a problem i
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Okay, I buy that.
https://reviews.llvm.org/D29144
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
boris.ulasevich added a comment.
Yes, it is quite old story. Original issue was that breakpoint with false
condition resumes execution in spite of completed step plan. There was two
local fix proposals, but finally the issue was fixed by
StopInfoBreakpoint::PerformAction and Thread::GetStopInfo
jingham added a comment.
If the problem is related to the handling of "don't stop at breakpoints"
expressions, can we fix it closer to there?
https://reviews.llvm.org/D29144
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llv
boris.ulasevich added a comment.
ping!
https://reviews.llvm.org/D29144
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
boris.ulasevich added a comment.
In https://reviews.llvm.org/D29144#659052, @jingham wrote:
> What's special about the TestCallThatThrows test?
Good question! It must be related with SetIgnoreBreakpoints(True) option used
in the test: with this option StopInfoBreakpoint::PerformAction is not
jingham added a comment.
If things were working generally the way your explanation states, then I don't
understand why this doesn't cause all expression evaluations to fail. We have
lots of tests that do expression evaluation. Why is only this test failing.
Your change looks reasonable to me
boris.ulasevich updated this revision to Diff 86091.
boris.ulasevich added a comment.
I made another diff with using GetCompletedPlan call. Hope it makes the code
clear.
https://reviews.llvm.org/D29144
Files:
lldb/source/Target/Process.cpp
Index: lldb/source/Target/Process.cpp
boris.ulasevich added a comment.
In https://reviews.llvm.org/D29144#657798, @jingham wrote:
> When you go to pick the plan to report for the stop it should be the top of
> the completed plan stack, the "thread plan to call function". Why in this
> particular case is the bottom of the completed
jingham added a comment.
Something else is going on then. The run to break point plan is just the
subsidiary plan that implements the call function plan. The way the function
call plan works is that finds some code which we know isn't going to get
executed (_start or something like it), write
boris.ulasevich added a comment.
I work on the case when we have two plans complete: internal breakpoint plus
our function call plan:
Active plan stack:
Element 0: Base thread plan.
Completed Plan Stack:
Element 0: Run to address: 0x00010e78be00 using breakpoint: 0 - but the
bre
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.
Can you explain in more detail the scenario this is addressing? You seem to be
handling a case where some plan has been completed, but it is not the function
call plan we are wait
boris.ulasevich created this revision.
Additional change for https://reviews.llvm.org/D26497,
https://reviews.llvm.org/D28945 - fix for TestCallThatThrows test fail (works
for Mac only).
Recent change of stop reason priorities affected function call mechanism: it is
important that CallFunction
13 matches
Mail list logo
