Re: [Lldb-commits] [lldb] r293269 - Unroll r292930 due to TestCallThatThrows test fail is not fixed in reasonable time.
Thanks for following up! It's really appreciated!
-Tim
On Thu, Jan 26, 2017 at 11:51 PM, Boris Ulasevich via lldb-commits <
lldb-commits@lists.llvm.org> wrote:
> Author: bulasevich
> Date: Fri Jan 27 01:51:43 2017
> New Revision: 293269
>
> URL: http://llvm.org/viewvc/llvm-project?rev=293269=rev
> Log:
> Unroll r292930 due to TestCallThatThrows test fail is not fixed in
> reasonable time.
>
> Removed:
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/
> step_over_breakpoint/
> Modified:
> lldb/trunk/include/lldb/Target/Thread.h
> lldb/trunk/include/lldb/Target/ThreadPlan.h
> lldb/trunk/source/Target/StopInfo.cpp
> lldb/trunk/source/Target/Thread.cpp
> lldb/trunk/source/Target/ThreadPlanStepInstruction.cpp
> lldb/trunk/source/Target/ThreadPlanStepRange.cpp
>
> Modified: lldb/trunk/include/lldb/Target/Thread.h
> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/
> lldb/Target/Thread.h?rev=293269=293268=293269=diff
>
> ==
> --- lldb/trunk/include/lldb/Target/Thread.h (original)
> +++ lldb/trunk/include/lldb/Target/Thread.h Fri Jan 27 01:51:43 2017
> @@ -126,7 +126,6 @@ public:
> // bit of data.
> lldb::StopInfoSP stop_info_sp; // You have to restore the stop info
> or you
> // might continue with the wrong
> signals.
> -std::vector m_completed_plan_stack;
> lldb::RegisterCheckpointSP
> register_backup_sp; // You need to restore the registers, of
> course...
> uint32_t current_inlined_depth;
> @@ -1030,15 +1029,6 @@ public:
>bool WasThreadPlanDiscarded(ThreadPlan *plan);
>
>//--
> - /// Check if we have completed plan to override breakpoint stop reason
> - ///
> - /// @return
> - /// Returns true if completed plan stack is not empty
> - /// false otherwise.
> - //--
> - bool CompletedPlanOverridesBreakpoint();
> -
> - //--
>/// Queues a generic thread plan.
>///
>/// @param[in] plan_sp
> @@ -1223,8 +1213,6 @@ public:
>
>void SetStopInfo(const lldb::StopInfoSP _info_sp);
>
> - void ResetStopInfo();
> -
>void SetShouldReportStop(Vote vote);
>
>//--
>
>
> Modified: lldb/trunk/include/lldb/Target/ThreadPlan.h
> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/include/
> lldb/Target/ThreadPlan.h?rev=293269=293268=293269=diff
>
> ==
> --- lldb/trunk/include/lldb/Target/ThreadPlan.h (original)
> +++ lldb/trunk/include/lldb/Target/ThreadPlan.h Fri Jan 27 01:51:43 2017
> @@ -40,10 +40,9 @@ namespace lldb_private {
> // The thread maintaining a thread plan stack, and you program the
> actions of a
> // particular thread
> // by pushing plans onto the plan stack.
> -// There is always a "Current" plan, which is the top of the plan stack,
> +// There is always a "Current" plan, which is the head of the plan stack,
> // though in some cases
> -// a plan may defer to plans higher in the stack for some piece of
> information
> -// (let us define that the plan stack grows downwards).
> +// a plan may defer to plans higher in the stack for some piece of
> information.
> //
> // The plan stack is never empty, there is always a Base Plan which
> persists
> // through the life
> @@ -110,15 +109,6 @@ namespace lldb_private {
> // plans in the time between when
> // your plan gets unshipped and the next resume.
> //
> -// Thread State Checkpoint:
> -//
> -// Note that calling functions on target process
> (ThreadPlanCallFunction) changes
> -// current thread state. The function can be called either by direct
> user demand or
> -// internally, for example lldb allocates memory on device to calculate
> breakpoint
> -// condition expression - on Linux it is performed by calling mmap on
> device.
> -// ThreadStateCheckpoint saves Thread state (stop info and completed
> -// plan stack) to restore it after completing function call.
> -//
> // Over the lifetime of the plan, various methods of the ThreadPlan are
> then
> // called in response to changes of state in
> // the process we are debugging as follows:
> @@ -159,7 +149,7 @@ namespace lldb_private {
> // If the Current plan answers "true" then it is asked if the stop should
> // percolate all the way to the
> // user by calling the ShouldStop method. If the current plan doesn't
> explain
> -// the stop, then we query up
> +// the stop, then we query down
> // the plan stack for a plan that does explain the stop. The plan that
> does
> // explain the stop then needs to
> // figure out what to do about the plans below it in
[Lldb-commits] [lldb] r293269 - Unroll r292930 due to TestCallThatThrows test fail is not fixed in reasonable time.
Author: bulasevich
Date: Fri Jan 27 01:51:43 2017
New Revision: 293269
URL: http://llvm.org/viewvc/llvm-project?rev=293269=rev
Log:
Unroll r292930 due to TestCallThatThrows test fail is not fixed in reasonable
time.
Removed:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/step_over_breakpoint/
Modified:
lldb/trunk/include/lldb/Target/Thread.h
lldb/trunk/include/lldb/Target/ThreadPlan.h
lldb/trunk/source/Target/StopInfo.cpp
lldb/trunk/source/Target/Thread.cpp
lldb/trunk/source/Target/ThreadPlanStepInstruction.cpp
lldb/trunk/source/Target/ThreadPlanStepRange.cpp
Modified: lldb/trunk/include/lldb/Target/Thread.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Thread.h?rev=293269=293268=293269=diff
==
--- lldb/trunk/include/lldb/Target/Thread.h (original)
+++ lldb/trunk/include/lldb/Target/Thread.h Fri Jan 27 01:51:43 2017
@@ -126,7 +126,6 @@ public:
// bit of data.
lldb::StopInfoSP stop_info_sp; // You have to restore the stop info or you
// might continue with the wrong signals.
-std::vector m_completed_plan_stack;
lldb::RegisterCheckpointSP
register_backup_sp; // You need to restore the registers, of course...
uint32_t current_inlined_depth;
@@ -1030,15 +1029,6 @@ public:
bool WasThreadPlanDiscarded(ThreadPlan *plan);
//--
- /// Check if we have completed plan to override breakpoint stop reason
- ///
- /// @return
- /// Returns true if completed plan stack is not empty
- /// false otherwise.
- //--
- bool CompletedPlanOverridesBreakpoint();
-
- //--
/// Queues a generic thread plan.
///
/// @param[in] plan_sp
@@ -1223,8 +1213,6 @@ public:
void SetStopInfo(const lldb::StopInfoSP _info_sp);
- void ResetStopInfo();
-
void SetShouldReportStop(Vote vote);
//--
Modified: lldb/trunk/include/lldb/Target/ThreadPlan.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/ThreadPlan.h?rev=293269=293268=293269=diff
==
--- lldb/trunk/include/lldb/Target/ThreadPlan.h (original)
+++ lldb/trunk/include/lldb/Target/ThreadPlan.h Fri Jan 27 01:51:43 2017
@@ -40,10 +40,9 @@ namespace lldb_private {
// The thread maintaining a thread plan stack, and you program the actions of
a
// particular thread
// by pushing plans onto the plan stack.
-// There is always a "Current" plan, which is the top of the plan stack,
+// There is always a "Current" plan, which is the head of the plan stack,
// though in some cases
-// a plan may defer to plans higher in the stack for some piece of information
-// (let us define that the plan stack grows downwards).
+// a plan may defer to plans higher in the stack for some piece of
information.
//
// The plan stack is never empty, there is always a Base Plan which persists
// through the life
@@ -110,15 +109,6 @@ namespace lldb_private {
// plans in the time between when
// your plan gets unshipped and the next resume.
//
-// Thread State Checkpoint:
-//
-// Note that calling functions on target process (ThreadPlanCallFunction)
changes
-// current thread state. The function can be called either by direct user
demand or
-// internally, for example lldb allocates memory on device to calculate
breakpoint
-// condition expression - on Linux it is performed by calling mmap on device.
-// ThreadStateCheckpoint saves Thread state (stop info and completed
-// plan stack) to restore it after completing function call.
-//
// Over the lifetime of the plan, various methods of the ThreadPlan are then
// called in response to changes of state in
// the process we are debugging as follows:
@@ -159,7 +149,7 @@ namespace lldb_private {
// If the Current plan answers "true" then it is asked if the stop should
// percolate all the way to the
// user by calling the ShouldStop method. If the current plan doesn't explain
-// the stop, then we query up
+// the stop, then we query down
// the plan stack for a plan that does explain the stop. The plan that does
// explain the stop then needs to
// figure out what to do about the plans below it in the stack. If the stop
is
@@ -180,7 +170,7 @@ namespace lldb_private {
// event it didn't directly handle
// it can designate itself a "Master" plan by responding true to IsMasterPlan,
// and then if it wants not to be
-// discarded, it can return false to OkayToDiscard, and it and all its
dependent
+// discarded, it can return true to OkayToDiscard, and it
