I was assuming that when a bit of inlined code was followed by code from the inlining site, it was going to execute to the inlining site code, but apparently that's not always true. So we need to be

I was assuming that when a bit of inlined code was followed by code from the inlining site, it was going to execute to the inlining site code, but apparently that's not always true. So we need to be a bit more careful getting past the inlining, and use a StepOverRange plan not a RunToAddress plan.

<rdar://problem/22191804>

llvm-svn: 244999

show more ...

Most thread plans don't handle eStopReasonInstrumentation stop reasons,
but that wasn't added to the list of reasons they don't explain. That
would mean we keep stepping after hitting the AsanDie br

Most thread plans don't handle eStopReasonInstrumentation stop reasons,
but that wasn't added to the list of reasons they don't explain. That
would mean we keep stepping after hitting the AsanDie breakpoint rather
than stopping when the Asan event occurred.

<rdar://problem/21925479>

llvm-svn: 243035

show more ...

Make many mangled functions that might demangle a name be allowed to specify a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so.

llv

Make many mangled functions that might demangle a name be allowed to specify a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so.

llvm-svn: 241751

show more ...

Fix a variety of typos.

No functional change.

llvm-svn: 239995

Move lldb-log.cpp to core/Logging.cpp

So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we a

Move lldb-log.cpp to core/Logging.cpp

So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".

llvm-svn: 232653

show more ...

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and t

This checkin is the first step in making the lldb thread stepping mechanism more accessible from
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.

I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.

llvm-svn: 218642

show more ...

When stepping, handle the case where the step leaves us with
the same parent frame, but different current frame - e.g. when
you step past a tail call exit from a function. Apply the same
"avoid-no-d

When stepping, handle the case where the step leaves us with
the same parent frame, but different current frame - e.g. when
you step past a tail call exit from a function. Apply the same
"avoid-no-debug" rules to this case as for a "step-in".

<rdar://problem/16189225>

llvm-svn: 214946

show more ...

If you found a step through plan stop looking up the stack for a step out plan.

llvm-svn: 214837

This commit reworks how the thread plan's ShouldStopHere mechanism works, so that it is useful not only
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), bu

This commit reworks how the thread plan's ShouldStopHere mechanism works, so that it is useful not only
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also
the behavior of step-in/step-out and step-over when they step out of the frame they started in.

I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame
into a frame with no debug information will continue stepping out till it arrives at a frame that does
have debug information. This is useful when you are debugging callback based code where the callbacks
are separated from the code that initiated them by some library glue you don't care about, among other
things.

llvm-svn: 203747

show more ...

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that

Roll back the changes I made in r193907 which created a new Frame
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.

llvm-svn: 193983

show more ...

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends ar

Add a new base class, Frame. It is a pure virtual function which
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.

Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.

This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.

I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.

<rdar://problem/15314068>

llvm-svn: 193907

show more ...

Examine more than 1 frame for equivalent contexts in ThreadPlanStepOverRange
- searches frames beginning from the current frame, stops when an equivalent context is found
- not using GetStackFrameCou

Examine more than 1 frame for equivalent contexts in ThreadPlanStepOverRange
- searches frames beginning from the current frame, stops when an equivalent context is found
- not using GetStackFrameCount() for performance reasons
- fixes TestInlineStepping (clang/gcc buildbots)

llvm-svn: 190868

show more ...

Correct logic error found by inspection.

From Jim's post on the lldb-dev mailing list:

This code is there as a backstop for when the unwinder drops a frame at
the beginning of new function/tram

Correct logic error found by inspection.

From Jim's post on the lldb-dev mailing list:

This code is there as a backstop for when the unwinder drops a frame at
the beginning of new function/trampoline or whatever.

In the (older_ctx_is_equivalent == false) case we will see if we are at
a trampoline function that somebody knows how to get out of, and
otherwise we will stop.

llvm-svn: 190149

show more ...

This commit does two things. One, it converts the return value of the QueueThreadPlanXXX
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the Thre

This commit does two things. One, it converts the return value of the QueueThreadPlanXXX
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further. If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.

<rdar://problem/14043602>

llvm-svn: 186618

show more ...

If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, just return the current PrivateStopInfo.

Also renamed a few more places where we were using StopReason in functions that

If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, just return the current PrivateStopInfo.

Also renamed a few more places where we were using StopReason in functions that were returning StopInfo's.

<rdar://problem/14042692>

llvm-svn: 183177

show more ...

Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached
value. This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop

Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached
value. This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh! I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.

Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming. That allows
us to handle resuming in a more controlled fashion.

Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--

M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M include/lldb/Target/ThreadList.h
M include/lldb/Target/ThreadPlanStepOut.h
M include/lldb/Target/Thread.h
M include/lldb/Target/ThreadPlanBase.h
M include/lldb/Target/ThreadPlanStepThrough.h
M include/lldb/Target/ThreadPlanStepInstruction.h
M include/lldb/Target/ThreadPlanStepInRange.h
M include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M include/lldb/Target/ThreadPlanStepUntil.h
M include/lldb/Target/StopInfo.h
M include/lldb/Target/Process.h
M include/lldb/Target/ThreadPlanRunToAddress.h
M include/lldb/Target/ThreadPlan.h
M include/lldb/Target/ThreadPlanCallFunction.h
M include/lldb/Target/ThreadPlanStepOverRange.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M source/Target/StopInfo.cpp
M source/Target/Process.cpp
M source/Target/ThreadPlanRunToAddress.cpp
M source/Target/ThreadPlan.cpp
M source/Target/ThreadPlanCallFunction.cpp
M source/Target/ThreadPlanStepOverRange.cpp
M source/Target/ThreadList.cpp
M source/Target/ThreadPlanStepOut.cpp
M source/Target/Thread.cpp
M source/Target/ThreadPlanBase.cpp
M source/Target/ThreadPlanStepThrough.cpp
M source/Target/ThreadPlanStepInstruction.cpp
M source/Target/ThreadPlanStepInRange.cpp
M source/Target/ThreadPlanStepOverBreakpoint.cpp
M source/Target/ThreadPlanStepUntil.cpp
M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme

llvm-svn: 181381

show more ...

<rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logg

<rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

llvm-svn: 178191

show more ...

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of t

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug
session.

<rdar://problem/12993641>

llvm-svn: 174793

show more ...

Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.

llvm-svn: 170800

<rdar://problem/12649160>

Added the ability to debug through your process exec'ing itself to the same architecture.

llvm-svn: 169340

Add a workaround to problems with the clang debug info for
inlined subroutine ranges.

<rdar://problem/12588579>

llvm-svn: 167430

Found a couple more places where we need to run all threads when stepping.

llvm-svn: 166732

Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of in

Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that
on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately. So for now its off.

llvm-svn: 163044

show more ...

Relax the test for "is the frame I am going to step back out to the one I started from" in ThreadPlanStepOverRange so you don't
artificially reject stepping out of a function you stepped into when st

Relax the test for "is the frame I am going to step back out to the one I started from" in ThreadPlanStepOverRange so you don't
artificially reject stepping out of a function you stepped into when stepping through an inlined range.

Also fill in the target in the symbol context we make up for the inlined stepping range in ThreadPlanStepOut.

<rdar://problem/11765912>

llvm-svn: 160794

show more ...

If the ObjC Step Through Trampoline plan causes a target crash, properly propagate the error back to
the controlling plans so that they don't lose control.

Also change "ThreadPlanStepThrough" to tak

If the ObjC Step Through Trampoline plan causes a target crash, properly propagate the error back to
the controlling plans so that they don't lose control.

Also change "ThreadPlanStepThrough" to take the return StackID for its backstop breakpoint as an argument
to the constructor rather than having it try to figure it out itself, since it might get it wrong whereas
the caller always knows where it is coming from.

rdar://problem/11402287

llvm-svn: 156529

show more ...