History log of /external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
04cc48eb5cff32268a822b57f87590c9dc2643f8 04-Jun-2013 Jim Ingham <jingham@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@183177 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
7c79a27b955432dfd3ad9439640f0af2eccf37b8 08-May-2013 Jim Ingham <jingham@apple.com> 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


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181381 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
23ed3ad96930e0b4d587bd429dca99f1f5f8bd16 28-Mar-2013 Jim Ingham <jingham@apple.com> The other half of the checkin to produce better error messages when the ThreadPlanCallFunction isn't valid.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178203 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
4f9103faba72fdfc4b4299d6d459bc820ee597b2 27-Feb-2013 Matt Kopec <Matt.Kopec@intel.com> Add GNU indirect function support in expressions for Linux.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176206 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
89e248f04ecb87d0df4a4b96158c3fac0a3e43c7 09-Feb-2013 Jim Ingham <jingham@apple.com> 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>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174793 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
b794020ffbd6473c59a6e98be044df50abf7fc30 15-Jan-2013 Jim Ingham <jingham@apple.com> Separated the "expr --unwind-on-error" behavior into two parts, actual errors (i.e. crashes) which continue to be
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.

<rdar://problem/12986644>
<rdar://problem/9119325>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172503 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
76b258db0611dad2f5b5ae51721a4bc0abd580ae 27-Nov-2012 Jim Ingham <jingham@apple.com> The Function calling thread plan was replacing the stored stop info too soon, causing recursive entry into the
breakpoint StopInfo's PerformAction, which is bad. Reworked this so that it is now correct.

<rdar://problem/12501259>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168634 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
110b55f22f8cda703c4fb6f1c2affb8ccbef215b 11-May-2012 Jim Ingham <jingham@apple.com> Don't try to use "OkayToDiscard" to mean BOTH this plan is a user plan or not AND unwind on error.

rdar://problem/11419156


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156627 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
038fa8e30621e0e55faed3479387d811986f28b7 10-May-2012 Jim Ingham <jingham@apple.com> 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


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156529 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
1e58cef33bbfd953e2c9e7dc872c4c74e0d75352 13-Apr-2012 Jim Ingham <jingham@apple.com> Factor out a bunch of common code in the two ThreadPlanCallFunction constructors. Also add a sanity check - try reading the frame, and if we fail bag out.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154698 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
2bcbaf625afd8f521da03ddaa146e7ea7650ee38 10-Apr-2012 Jim Ingham <jingham@apple.com> Rework how master plans declare themselves. Also make "PlanIsBasePlan" not rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
016ef8886cd429f8a53bff967e601f831e409eaa 22-Dec-2011 Jim Ingham <jingham@apple.com> Improve the x86_64 return value decoder to handle most structure returns.
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147157 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
ba560cc7d03c9f7d9df81e60201c5ec75cff5232 01-Nov-2011 Jim Ingham <jingham@apple.com> Enhanced the ObjC DynamicCheckerFunction to test for "object responds to selector" as well as
"object borked"... Also made the error when the checker fails reflect this fact rather than
report a crash at 0x0.

Also a little cleanup:
- StopInfoMachException had a redundant copy of the description string.
- ThreadPlanCallFunction had a redundant copy of the thread, and had a
copy of the process that it didn't really need.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143419 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
2370a97fe5bea6fa9d82f40bb34d37d3d3bda317 17-May-2011 Jim Ingham <jingham@apple.com> Fix the error message when an expression evaluation is interrupted by a crash/breakpoint hit to
give the reason for the interrupt. Also make sure it we don't want to unwind from the evaluation
we print something if it is interrupted.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131448 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
2f085c6ca2895663687dca704589478ff040b849 15-May-2011 Greg Clayton <gclayton@apple.com> Added the ability to get the return value from a ThreadPlanCallFunction
thread plan. In order to get the return value, you can call:

void
ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp);

This registers a shared pointer to a return value that will get filled in if
everything goes well. After the thread plan is run the return value will be
extracted for you.

Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT.
We currently have the standard JIT selected because we have some work to do to
get the MCJIT fuctioning properly.

Added the ability to call functions with 6 argument in the x86_64 ABI.

Added the ability for GDBRemoteCommunicationClient to detect if the allocate
and deallocate memory packets are supported and to not call allocate memory
("_M") or deallocate ("_m") if we find they aren't supported.

Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...)
to be able to deal with the allocate and deallocate memory packets not being
supported. If they are not supported, ProcessGDBRemote will switch to calling
"mmap" and "munmap" to allocate and deallocate memory instead using our
trivial function call support.

Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore
the qHostInfo triple information if any was specified in the target. Currently
if the target only specifies an architecture when creating the target:

(lldb) target create --arch i386 a.out

Then the vendor, os and environemnt will be adopted by the target.

If the target was created with any triple that specifies more than the arch:

(lldb) target create --arch i386-unknown-unknown a.out

Then the target will maintain its triple and not adopt any new values. This
can be used to help force bare board debugging where the dynamic loader for
static files will get used and users can then use "target modules load ..."
to set addressses for any files that are desired.

Added back some convenience functions to the lldb_private::RegisterContext class
for writing registers with unsigned values. Also made all RegisterContext
constructors explicit to make sure we know when an integer is being converted
to a RegisterValue.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
989816b9505219cd67ce044d655c54ac86ecf64b 14-May-2011 Greg Clayton <gclayton@apple.com> Expand the ABI prepare trivial function call to allow 6 simple args.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131334 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
0ddf806dd9e71637846bf0ad46e1b2df7d02cbce 10-May-2011 Sean Callanan <scallanan@apple.com> Fixed a bug in which expression-local variables were
treated as being permanently resident in target
memory. In fact, since the expression's stack frame
is deleted and potentially re-used after the
expression completes, the variables need to be treated
as being freeze-dried.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131104 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
cce607b039a7636f50f53b3ed52f6e8db99fffd5 22-Jan-2011 Jim Ingham <jingham@apple.com> Centralize the register reporting (might want to move this function to Thread).


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124016 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
15dcb7ca49b8d8f46910cf085b4c249aac5317fa 20-Jan-2011 Jim Ingham <jingham@apple.com> Back up both the register AND the stop state when calling functions.
Set the thread state to "bland" before calling functions so they don't
inherit the pending signals and die.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123869 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
3e2ef48cd65658162791134b34c3c1fb9e8c8991 19-Jan-2011 Jim Ingham <jingham@apple.com> ThreadPlanCallUserExpression's WillPop needs to call it's parent's WillPop.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123816 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
6c9662e0e5840b557fcd4bd990620e106e4a18e2 18-Jan-2011 Jim Ingham <jingham@apple.com> In ThreadPlanCallFunction, do the Takedown right when the thread plan gets popped. When the function call is discarded (e.g. when it crashes and discard_on_error is true) the plan gets discarded. You need to make sure that the stack gets restored right then, and not wait till you start again and the thread plan stack is cleared.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123716 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
3aa7da5cb3327792415de44405e0896c6bdc305b 13-Dec-2010 Sean Callanan <scallanan@apple.com> Added support for generating expressions that have
access to the members of the Objective-C self object.

The approach we take is to generate the method as a
@category on top of the self object, and to pass the
"self" pointer to it. (_cmd is currently NULL.)

Most changes are in ClangExpressionDeclMap, but the
change that adds support to the ABIs to pass _cmd
touches a fair amount of code.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121722 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
48685687640e88515cd17b6fa613d13e180558d6 12-Nov-2010 Sean Callanan <scallanan@apple.com> Excised a version of the low-level function calling
logic that supported calling functions with arbitrary
arguments. We use ClangFunction for this, and the
low-level logic is only required to support one or two
pointer arguments.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118871 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
745ac7a5826fe7c392007941a4046bfb1a8dff81 11-Nov-2010 Jim Ingham <jingham@apple.com> Add ThreadPlanTracer class to allow instruction step tracing of execution.
Also changed eSetVarTypeBool to eSetVarTypeBoolean to make it consistent with eArgTypeBoolean.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118824 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
14a97ff7ccb8d40fee3c6ff136a2c602819174dd 04-Nov-2010 Sean Callanan <scallanan@apple.com> Re-enabled LLDB's pointer checkers, and moved the
implementation of the Objective-C object checkers
into the Objective-C language runtime.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118226 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
29756d452be39535ded2cff50d9db4df46fe6400 03-Nov-2010 Sean Callanan <scallanan@apple.com> Factored the code that implements breakpoints on
exceptions for different languages out of
ThreadPlanCallFunction and put it into the
appropriate language runtimes.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118200 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
94fb5432f10882f8917acb7849abdba7c61277ac 03-Nov-2010 Sean Callanan <scallanan@apple.com> Modified ThreadPlanCallFunction to perform the
exception checks at the right time, and modified
ClangFunction so that it doesn't misinterpret the
stop as a timeout stop.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
07f3d8d674350e5efc7f762f18c82c8c6f2abb10 03-Nov-2010 Sean Callanan <scallanan@apple.com> Modified the thread plan that calls functions to
set breakpoints at the different locations where
an exception could be thrown, so that exceptions
thrown by expressions are properly caught.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118142 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
3c9c5eb466869ede185e879d14a47335fb43194d 21-Sep-2010 Sean Callanan <scallanan@apple.com> Removed the hacky "#define this ___clang_this" handler
for C++ classes. Replaced it with a less hacky approach:

- If an expression is defined in the context of a
method of class A, then that expression is wrapped as
___clang_class::___clang_expr(void*) { ... }
instead of ___clang_expr(void*) { ... }.

- ___clang_class is resolved as the type of the target
of the "this" pointer in the method the expression
is defined in.

- When reporting the type of ___clang_class, a method
with the signature ___clang_expr(void*) is added to
that class, so that Clang doesn't complain about a
method being defined without a corresponding
declaration.

- Whenever the expression gets called, "this" gets
looked up, type-checked, and then passed in as the
first argument.

This required the following changes:

- The ABIs were changed to support passing of the "this"
pointer as part of trivial calls.

- ThreadPlanCallFunction and ClangFunction were changed
to support passing of an optional "this" pointer.

- ClangUserExpression was extended to perform the
wrapping described above.

- ClangASTSource was changed to revert the changes
required by the hack.

- ClangExpressionParser, IRForTarget, and
ClangExpressionDeclMap were changed to handle
different manglings of ___clang_expr flexibly. This
meant no longer searching for a function called
___clang_expr, but rather looking for a function whose
name *contains* ___clang_expr.

- ClangExpressionParser and ClangExpressionDeclMap now
remember whether "this" is required, and know how to
look it up as necessary.

A few inheritance bugs remain, and I'm trying to resolve
these. But it is now possible to use "this" as well as
refer implicitly to member variables, when in the proper
context.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114384 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Target/ThreadPlanCallFunction.h