summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/ThreadPlanStepOverRange.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Fix step-over when SymbolContext.function is missing and symbol is present.Sam McCall2016-11-171-14/+15
| | | | | | | | | | | | | | | | | | | | | | | Summary: Fix step-over when SymbolContext.function is missing and symbol is present. With targets from our build configuration, ThreadPlanStepOverRange::IsEquivalentContext fails to fire for relevant frames, leading to ShouldStop() returning true prematurely. The frame's SymbolContext, and m_addr_context have: - comp_unit set and matching - function = nullptr - symbol set and matching (but this is never checked) My naive guess is that the context should be equivalent in this case :-) Reviewers: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26804 llvm-svn: 287274
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-1/+1
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-368/+362
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Some code that is sanity checking stepping out back out from one inlinedJim Ingham2016-07-291-0/+6
| | | | | | | | | frame to another was triggering an early stop when stepping back out to a real frame. Check that we're doing this only for inlined frames. <rdar://problem/26482931> llvm-svn: 277185
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-3/+3
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* Re-apply r257117 (reverted in r257138 temporarily),Jason Molenda2016-01-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the one change that ThreadPlanStepOut::ThreadPlanStepOut will now only advance the return address breakpoint to the end of a source line, if we have source line debug information. It will not advance to the end of a Symbol if we lack source line information. This, or the recognition of the LEAVE instruction in r257209, would have fixed the regression that Siva was seeing. Both were good changes, so I've made both. Original commit message: Performance improvement: Change lldb so that it puts a breakpoint on the first branch instruction after a function return (or the end of a source line), instead of a breakpoint on the return address, to skip an extra stop & start of the inferior process. I changed Process::AdvanceAddressToNextBranchInstruction to not take an optional InstructionList argument - no callers are providing a cached InstructionList today, and if this function was going to do that, the right thing to do would be to fill out / use a DisassemblerSP which is a disassembler with the InstructionList for this address range. http://reviews.llvm.org/D15708 <rdar://problem/23309838> llvm-svn: 257210
* Revert r257117 "Performance improvement: Change lldb so that itJason Molenda2016-01-081-2/+1
| | | | | | | | puts a breakpoint" it is causing a regression in the TestStepNoDebug test case on ubuntu 14.04 with gcc 4.9.2. Thanks for the email Siva. I'll recommit when I've figured out the regression. llvm-svn: 257138
* Performance improvement: Change lldb so that it puts a breakpointJason Molenda2016-01-081-1/+2
| | | | | | | | | | | | | | | | | | | on the first branch instruction after a function return (or the end of a source line), instead of a breakpoint on the return address, to skip an extra stop & start of the inferior process. I changed Process::AdvanceAddressToNextBranchInstruction to not take an optional InstructionList argument - no callers are providing a cached InstructionList today, and if this function was going to do that, the right thing to do would be to fill out / use a DisassemblerSP which is a disassembler with the InstructionList for this address range. http://reviews.llvm.org/D15708 <rdar://problem/23309838> llvm-svn: 257117
* Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr ↵Eugene Zelenko2015-12-151-27/+11
| | | | | | | | warnings in some files in source/Target/. Simplify smart pointers checks in conditions. Other minor fixes. llvm-svn: 255598
* I was assuming that when a bit of inlined code was followed by code from the ↵Jim Ingham2015-08-141-4/+8
| | | | | | | | 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
* Most thread plans don't handle eStopReasonInstrumentation stop reasons,Jim Ingham2015-07-231-12/+7
| | | | | | | | | | 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
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-1/+1
| | | | | | 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
* Fix a variety of typos.Bruce Mitchener2015-06-181-2/+2
| | | | | | No functional change. llvm-svn: 239995
* Move lldb-log.cpp to core/Logging.cppZachary Turner2015-03-181-2/+0
| | | | | | | | | 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
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-4/+22
| | | | | | | | | | | | 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
* When stepping, handle the case where the step leaves us withJim Ingham2014-08-061-0/+4
| | | | | | | | | | 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
* If you found a step through plan stop looking up the stack for a step out plan.Jim Ingham2014-08-051-0/+3
| | | | llvm-svn: 214837
* This commit reworks how the thread plan's ShouldStopHere mechanism works, so ↵Jim Ingham2014-03-131-8/+43
| | | | | | | | | | | | | | | 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
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-3/+3
| | | | | | | | | | 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
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-3/+3
| | | | | | | | | | | | | | | | | | | | | 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
* Examine more than 1 frame for equivalent contexts in ThreadPlanStepOverRangeDaniel Malea2013-09-171-36/+40
| | | | | | | | - 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
* Correct logic error found by inspection.Ed Maste2013-09-061-1/+1
| | | | | | | | | | | | | 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
* This commit does two things. One, it converts the return value of the ↵Jim Ingham2013-07-181-9/+9
| | | | | | | | | | | | | 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
* If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, ↵Jim Ingham2013-06-041-1/+1
| | | | | | | | | | 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
* Figure out the reply to "PlanExplainsStop" once when we stop and then use ↵Jim Ingham2013-05-081-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/13521159>Greg Clayton2013-03-271-3/+3
| | | | | | | | 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
* Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction ↵Jim Ingham2013-02-091-1/+1
| | | | | | | | | | | 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
* Adding eStopReasonThreadExiting and fixing the handling of this state on Linux.Andrew Kaylor2012-12-201-0/+1
| | | | llvm-svn: 170800
* <rdar://problem/12649160>Greg Clayton2012-12-051-0/+1
| | | | | | 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 Jim Ingham2012-11-061-0/+95
| | | | | | | | inlined subroutine ranges. <rdar://problem/12588579> llvm-svn: 167430
* Found a couple more places where we need to run all threads when stepping.Jim Ingham2012-10-251-1/+1
| | | | llvm-svn: 166732
* Initial check-in of "fancy" inlined stepping. Doesn't do anything useful ↵Jim Ingham2012-09-011-8/+60
| | | | | | | | | 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
* Relax the test for "is the frame I am going to step back out to the one I ↵Jim Ingham2012-07-261-1/+30
| | | | | | | | | | | | 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
* If the ObjC Step Through Trampoline plan causes a target crash, properly ↵Jim Ingham2012-05-101-3/+3
| | | | | | | | | | | | | | 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
* Clean up the usage of "MasterPlan" status in ThreadPlans. Only ↵Jim Ingham2012-05-031-6/+1
| | | | | | | | | | | | | | | user-initiated plans should be MasterPlans that want to stay on the plan stack. So make all plans NOT MasterPlans by default and then have the SB API's and the CommandObjectThread step commands set this explicitly. Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded on the stack, we can remove them. This is done by adding an IsPlanStale method to the thread plans, and if the plan can know that it is no longer relevant, it returns true, and the plan and its sub-plans will get discarded. llvm-svn: 156101
* Fix reporting of stop reasons when the StepOver & StepIn plans stop because ↵Jim Ingham2012-05-011-0/+38
| | | | | | of a crash or breakpoint. Added the ability for a plan to say it is done but doesn't want to be the reason for the stop. llvm-svn: 155927
* Rework how master plans declare themselves. Also make "PlanIsBasePlan" not ↵Jim Ingham2012-04-091-0/+3
| | | | | | rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such. llvm-svn: 154351
* First stage of implementing step by "run to next branch". Doesn't work yet, ↵Jim Ingham2012-03-091-35/+20
| | | | | | | | is turned off. <rdar://problem/10975912> llvm-svn: 152376
* Convert the thread plans over from using the stack count to do their logic ↵Jim Ingham2012-03-011-10/+29
| | | | | | | | to using StackID's. This should be more efficient. llvm-svn: 151780
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-1/+1
| | | | | | | | | | | | | | | | | objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
* Make the ThreadPlanStepThrough set a backstop breakpoint on the return ↵Jim Ingham2011-12-031-0/+25
| | | | | | | | | | | | | | address from the function it is being asked to step through, so that even if we get the trampoline target wrong (for instance) we will still not lose control. The other fix here is to tighten up the handling of the case where the current plan doesn't explain the stop, but a plan above us does. In that case, if the plan that does explain the stop says it is done, we need to clean up the plans below it and continue on with our processing. llvm-svn: 145740
* Make the step range plans capable of supporting multiple ranges. Also make ↵Jim Ingham2011-10-151-1/+1
| | | | | | their constructors public, there isn't any good reason why you shouldn't be able to make these plans. llvm-svn: 142026
* Fixed the LLDB build so that we can have private types, private enums andGreg Clayton2011-03-241-2/+2
| | | | | | | | public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better. llvm-svn: 128239
* Made lldb_private::ArchSpec contain much more than just an architecture. ItGreg Clayton2011-02-151-1/+3
| | | | | | | | | | now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
* Added support for stepping out of a frame. If you have 10 stack frames, and you Greg Clayton2011-01-211-1/+7
| | | | | | | | | | select frame #3, you can then do a step out and be able to go directly to the frame above frame #3! Added StepOverUntil and StepOutOfFrame to the SBThread API to allow more powerful stepping. llvm-svn: 123970
* Modified all logging calls to hand out shared pointers to make sure weGreg Clayton2010-11-061-1/+2
| | | | | | | | | | | don't crash if we disable logging when some code already has a copy of the logger. Prior to this fix, logs were handed out as pointers and if they were held onto while a log got disabled, then it could cause a crash. Now all logs are handed out as shared pointers so this problem shouldn't happen anymore. We are also using our new shared pointers that put the shared pointer count and the object into the same allocation for a tad better performance. llvm-svn: 118319
* Handle stepping through ObjC vtable trampoline code.Jim Ingham2010-11-051-1/+13
| | | | llvm-svn: 118270
* Moved the section load list up into the target so we can use the targetGreg Clayton2010-09-141-1/+1
| | | | | | to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
* Two changes in this checkin. Added a ThreadPlanKind so that I can do some ↵Jim Ingham2010-06-191-1/+1
| | | | | | | | | | | reasoning based on the kind of thread plan without having to use RTTI. Removed the ThreadPlanContinue and replaced with a ShouldAutoContinue query that serves the same purpose. Having to push another plan to assert that if there's no other indication the target should continue when this plan is popped was flakey and error prone. This method is more stable, and fixed problems we were having with thread specific breakpoints. llvm-svn: 106378
OpenPOWER on IntegriCloud