summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/ThreadPlanStepRange.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr ↵Eugene Zelenko2015-12-151-31/+12
| | | | | | | | warnings in some files in source/Target/. Simplify smart pointers checks in conditions. Other minor fixes. llvm-svn: 255598
* When constructing an address range to "step" or "next" through,Jason Molenda2015-12-151-2/+2
| | | | | | | | | | | | | | find the largest address range (possibly combining multiple LineEntry's for this line number) that is contiguous. This allows lldb's fast-step stepping algorithm to potentially run for a longer address range than if we have to stop at every LineEntry indicating a subexpression in the source line. http://reviews.llvm.org/D15407 <rdar://problem/23270882> llvm-svn: 255590
* Fix commit 252963 to work around a bug on some platforms where they don't Jim Ingham2015-11-131-3/+13
| | | | | | | | correctly handle stepping over one breakpoint directly onto another breakpoint. This isn't fixing that bug, but rather just changing 252963 to not use breakpoints if it is only stepping one instruction. llvm-svn: 253008
* Revert "Another little stepping optimization: if any of the source step ↵Ying Chen2015-11-131-9/+2
| | | | | | | | | | commands are running through a range " - Revert because this commit introduce several failures in lldb test suite - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391 - This reverts commit 78943bb678c2893703ee4e8b41969372740c8a6f. llvm-svn: 252980
* Another little stepping optimization: if any of the source step commands are ↵Jim Ingham2015-11-121-2/+9
| | | | | | | | | | | | | | | | | | | | | running through a range of addresses, and the range has no branches, instead of running to the last instruction and single-stepping over that, run to the first instruction after the end of the range. If there are no branches in the current range, then the bytes right after it have to be in the current function, and have to be instructions not data in code, so this is safe. And it cuts down one extra stepi per source range step. Incidentally, this also works around a bug in the llvm Intel assembler where it treats the "rep" prefix as a separate instruction from the repeated instruction. If that were at the end of a line range, then we would put a trap in place of the repeated instruction, which is undefined behavior. Current processors just ignore the repetition in this case, which changes program behavior. Since there would never be a line range break after the rep prefix, always doing the range stepping to the beginning of the new range avoids this problem. <rdar://problem/23461686> llvm-svn: 252963
* Fix compiler warning in ThreadPlanStepRangePavel Labath2015-07-161-1/+1
| | | | llvm-svn: 242403
* Small fix to ThreadPlanStepRange::DumpRanges to loggingJason Molenda2015-07-141-1/+1
| | | | | | output when stepping through multiple ranges. llvm-svn: 242243
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-2/+2
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Add Hexagon packet support to ThreadPlanStepRangeTed Woodward2015-05-111-1/+2
| | | | | | | | | | | | | | | | | Summary: Hexagon is a VLIW processor. It can execute multiple instructions at once, called a packet. Breakpoints need to be alone in a packet. This patch will make sure that temporary breakpoints used for stepping are set at the start of a packet, which will put the breakpoint in a packet by itself. Patch by Deepak Panickal of CodePlay and Ted Woodward of Qualcomm. Reviewers: deepak2427, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9437 llvm-svn: 237047
* 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-3/+5
| | | | | | | | | | | | 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
* Fetching the parent frame may fail, handle that case. Patch from Tong Shen.Jim Ingham2014-08-111-2/+7
| | | | llvm-svn: 215411
* When stepping, handle the case where the step leaves us withJim Ingham2014-08-061-1/+9
| | | | | | | | | | 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
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-031-2/+2
| | | | llvm-svn: 202723
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-1/+1
| | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* <rdar://problem/13635174>Greg Clayton2013-10-111-1/+1
| | | | | | | | Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging. Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function. llvm-svn: 192491
* DWARF says line number 0 is a valid line number - used to indicate a source ↵Jim Ingham2013-09-271-0/+19
| | | | | | | | | | line that should not have breakpoints set on it inserted into code that does have a valid line number. So allow that line number, and the ThreadPlanStepRange should just continue stepping over 0 line ranges as if they had the same line number as whatever we were previously stepping through. llvm-svn: 191477
* Disassembler::DisassembleRange() currently calls Target::ReadMemoryJason Molenda2013-09-121-1/+3
| | | | | | | | | | | | | with prefer_file_cache == false. This is what we want to do when the user is doing a disassemble command -- show the actual memory contents in case the memory has been corrupted or something -- but when we're profiling functions for stepping or unwinding (ThreadPlanStepRange::GetInstructionsForAddress, UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read __TEXT instructions directly out of the file, if it exists. <rdar://problem/14397491> llvm-svn: 190638
* Re-enable fast stepping for arm targets. The issue being workedJason Molenda2013-08-011-5/+1
| | | | | | | around was fixed in llvm commit r186846. <rdar://problem/14489274> llvm-svn: 187620
* The DisassemblerLLVMC has a retain cycle - the InstructionLLVMC's contained ↵Jim Ingham2013-07-311-0/+13
| | | | | | | | | | | | in its instruction list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this for real when I have time to do so. <rdar://problem/14581918> llvm-svn: 187473
* Turn off fast stepping for ARM till the MC's MayAffectControlFlow gets more ↵Jim Ingham2013-07-191-1/+5
| | | | | | | | accurate. rdar://problem/14488761 llvm-svn: 186646
* <rdar://problem/13521159>Greg Clayton2013-03-271-7/+7
| | | | | | | | 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
* Add a target setting (target.use-fast-stepping) to control using the "run to ↵Jim Ingham2013-03-131-0/+1
| | | | | | next branch" stepping algorithm. llvm-svn: 176958
* The step by running from branch to branch pretty much works with this ↵Jim Ingham2013-03-131-7/+61
| | | | | | | | | checkin (at least for x86_64) but is still turned off, it needs more qualification. If you want to play with it, change the initialization of m_use_fast_step to true. llvm-svn: 176923
* Convert from the C-based LLVM Disassembler shim to the full MC Disassembler ↵Jim Ingham2013-03-021-1/+4
| | | | | | | | | | | | API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
* Add "target.process.stop-on-shared-library-events" setting, and make it work.Jim Ingham2013-01-261-2/+7
| | | | | | | | | | | Add the ability to give breakpoints a "kind" string, and have the StopInfoBreakpoint print that in the brief description if set. Also print the kind - if set - in the breakpoint listing. Give kinds to a bunch of the internal breakpoints. We were deleting the Mac OS X dynamic loader breakpoint as though the id we had stored away was a breakpoint site ID, but in fact it was a breakpoint id, so we never actually deleted it. Fixed that. llvm-svn: 173555
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-1/+1
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Shortcut ThreadPlanStepRange::MischiefManaged - if we have pushed new plans ↵Jim Ingham2012-09-101-6/+20
| | | | | | | | and they are not done, then we aren't done either. <rdar://problem/12259124> llvm-svn: 163572
* Clean up the usage of "MasterPlan" status in ThreadPlans. Only ↵Jim Ingham2012-05-031-0/+27
| | | | | | | | | | | | | | | 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-36/+0
| | | | | | 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
* Make sure the "synchronous breakpoint callbacks" get called before the ↵Jim Ingham2012-04-201-0/+3
| | | | | | | | | | | thread plan logic gets invoked, and if they ask to continue that should short-circuit the thread plans for that thread. Also add a bit more explanation for how this machinery is supposed to work. Also pass eExecutionPolicyOnlyWhenNeeded, not eExecutionPolicyAlways when evaluating the expression for breakpoint conditions. llvm-svn: 155236
* First stage of implementing step by "run to next branch". Doesn't work yet, ↵Jim Ingham2012-03-091-1/+156
| | | | | | | | is turned off. <rdar://problem/10975912> llvm-svn: 152376
* <rdar://problem/10997402>Greg Clayton2012-03-071-2/+3
| | | | | | | | | | | This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
* Convert the thread plans over from using the stack count to do their logic ↵Jim Ingham2012-03-011-50/+20
| | | | | | | | 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-8/+8
| | | | | | | | | | | | | | | | | 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-24/+0
| | | | | | | | | | | | | | 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-6/+45
| | | | | | their constructors public, there isn't any good reason why you shouldn't be able to make these plans. llvm-svn: 142026
* If stepping takes us from the line range we were stepping through into the ↵Jim Ingham2011-09-231-9/+33
| | | | | | MIDDLE of another line, then continue till we get to the real beginning of a line. This is mostly to work around debug information bugs. llvm-svn: 140416
* Formatting.Jim Ingham2011-02-081-1/+6
| | | | llvm-svn: 125076
* Fixed incorrect logging printf (patch from Stephen Wilson).Greg Clayton2011-01-181-1/+1
| | | | llvm-svn: 123780
* Add ThreadPlanTracer class to allow instruction step tracing of execution.Jim Ingham2010-11-111-1/+1
| | | | | | Also changed eSetVarTypeBool to eSetVarTypeBoolean to make it consistent with eArgTypeBoolean. llvm-svn: 118824
* Modified all logging calls to hand out shared pointers to make sure weGreg Clayton2010-11-061-5/+5
| | | | | | | | | | | 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
* Don't cache the public stop reason, since it can change as plan completion ↵Jim Ingham2010-10-201-3/+3
| | | | | | gets processed. That means GetStopReason needs to return a shared pointer, not a pointer to the thread's cached version. Also allow the thread plans to get and set the thread private stop reason - that is usually more appropriate for the logic the thread plans need to do. llvm-svn: 116892
* Step past prologues when we step into functions.Jim Ingham2010-09-161-0/+4
| | | | llvm-svn: 114055
* Moved the section load list up into the target so we can use the targetGreg Clayton2010-09-141-6/+4
| | | | | | to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
* Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope.Greg Clayton2010-09-031-4/+6
| | | | | | | | | Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
* Abtracted the old "lldb_private::Thread::StopInfo" into an abtract class.Greg Clayton2010-08-041-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow debugger plug-ins to make any instance of "lldb_private::StopInfo" that can completely describe any stop reason. It also provides a framework for doing intelligent things with the stop info at important times in the lifetime of the inferior. Examples include the signal stop info in StopInfoUnixSignal. It will check with the process to see that the current action is for the signal. These actions include wether to stop for the signal, wether the notify that the signal was hit, and wether to pass the signal along to the inferior process. The StopInfoUnixSignal class overrides the "ShouldStop()" method of StopInfo and this allows the stop info to determine if it should stop at the signal or continue the process. StopInfo subclasses must override the following functions: virtual lldb::StopReason GetStopReason () const = 0; virtual const char * GetDescription () = 0; StopInfo subclasses can override the following functions: // If the subclass returns "false", the inferior will resume. The default // version of this function returns "true" which means the default stop // info will stop the process. The breakpoint subclass will check if // the breakpoint wants us to stop by calling any installed callback on // the breakpoint, and also checking if the breakpoint is for the current // thread. Signals will check if they should stop based off of the // UnixSignal settings in the process. virtual bool ShouldStop (Event *event_ptr); // Sublasses can state if they want to notify the debugger when "ShouldStop" // returns false. This would be handy for breakpoints where you want to // log information and continue and is also used by the signal stop info // to notify that a signal was received (after it checks with the process // signal settings). virtual bool ShouldNotify (Event *event_ptr) { return false; } // Allow subclasses to do something intelligent right before we resume. // The signal class will figure out if the signal should be propagated // to the inferior process and pass that along to the debugger plug-ins. virtual void WillResume (lldb::StateType resume_state) { // By default, don't do anything } The support the Mach exceptions was moved into the lldb/source/Plugins/Process/Utility folder and now doesn't polute the lldb_private::Thread class with platform specific code. llvm-svn: 110184
* Properly set the PlanKind for the ThreadPlanStepRange derived classes.Jim Ingham2010-07-101-1/+1
| | | | llvm-svn: 108035
* Merged Eli Friedman's linux build changes where he added Makefile files thatGreg Clayton2010-07-091-2/+2
| | | | | | | enabled LLVM make style building and made this compile LLDB on Mac OS X. We can now iterate on this to make the build work on both linux and macosx. llvm-svn: 108009
OpenPOWER on IntegriCloud