summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/StackFrameList.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fiddle with the heuristic about where to set the stop point in a nested ↵Jim Ingham2012-09-081-0/+27
| | | | | | | | inline stack when we get there by breakpoint. If we hit a user breakpoint, I set the stop point to the bottom-most frame 'cause that's what we did before. <rdar://problem/12258999> Setting breakpoint in always inline function is stopping in function above it llvm-svn: 163439
* Add SetCurrentInlinedDepth API.Jim Ingham2012-09-071-5/+27
| | | | | | In GetFramesUpTo, don't adjust the number of frames for the inlined depth if the number of frames in UINT32_MAX. llvm-svn: 163432
* For now, treat breakpoint hits like regular stops when calculation ↵Jim Ingham2012-09-071-5/+6
| | | | | | InlinedStackDepth. llvm-svn: 163365
* When you reach the bottom of the inlined stack, don't say you can do a ↵Jim Ingham2012-09-061-1/+6
| | | | | | virtual step. llvm-svn: 163341
* Turn on the "fancy inlined stepping."Jim Ingham2012-09-051-3/+1
| | | | llvm-svn: 163246
* Initial check-in of "fancy" inlined stepping. Doesn't do anything useful ↵Jim Ingham2012-09-011-2/+172
| | | | | | | | | 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
* <rdar://problem/11852100>Greg Clayton2012-07-111-6/+2
| | | | | | The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-2/+2
| | | | | | | | | | | | | No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221
* If the unwinder fails to make us a frame 0, make one by hand from the SP & PC.Jim Ingham2012-03-011-12/+12
| | | | llvm-svn: 151793
* Use the correct (computed by the unwinder) CallFrameAddress as the CFA for ↵Jim Ingham2012-02-291-26/+18
| | | | | | Frame 0 rather than using the stack pointer which is not constant over the life of the frame. llvm-svn: 151744
* Make the StackFrameList::GetFrameAtIndex only fetch as many stack frames as ↵Jim Ingham2012-02-291-158/+187
| | | | | | | | | needed to get the frame requested. <rdar://problem/10943135> llvm-svn: 151705
* Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton2012-02-211-2/+2
| | | | | | | | | | | | | | | | | 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
* The second part in thread hardening the internals of LLDB where we makeGreg Clayton2012-02-181-8/+8
| | | | | | | | | | | | | | | | the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
* This checking is part one of trying to add some threading safety to ourGreg Clayton2012-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
* Fixed the Xcode project building of LLVM to be a bit more user friendly:Greg Clayton2011-11-041-1/+1
| | | | | | | | | | | | | | | | | | | - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
* <rdar://problem/10226227>Greg Clayton2011-10-071-1/+9
| | | | | | | Fixed the root cause of what was causing an assertion to fire during single stepping. We had an issue with the inlined stack frames where when we had inlined frames that were not in the first concrete frame where we passed the wrong PC down. We needed to decrement the PC by one for these frames to make sure we are using the same address that did the symbol context lookup. llvm-svn: 141349
* Fixed a crasher where the m_frames collection was being accessed withoutGreg Clayton2011-10-051-3/+4
| | | | | | using the mutex. llvm-svn: 141160
* Cleaned up the the code that figures out the inlined stack frames given a Greg Clayton2011-10-011-49/+13
| | | | | | | | | | | | | | | | | | | | | | | | symbol context that represents an inlined function. This function has been renamed internally to: bool SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc, SymbolContext &next_frame_sc, Address &next_frame_pc) const; And externally to: SBSymbolContext SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc, SBAddress &parent_frame_addr) const; The correct blocks are now correctly calculated. Switched the stack backtracing engine (in StackFrameList) and the address context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...) so all inlined callstacks will match exactly. llvm-svn: 140910
* Update declarations for all functions/methods that accept printf-styleJason Molenda2011-09-201-1/+1
| | | | | | | | stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
* Move the SourceManager from the Debugger to the Target. That way it can ↵Jim Ingham2011-09-081-2/+22
| | | | | | | | | | store the per-Target default Source File & Line. Set the default Source File & line to main (if it can be found.) at startup. Selecting the current thread & or frame resets the current source file & line, and "source list" as well as the breakpoint command "break set -l <NUM>" will use the current source file. llvm-svn: 139323
* Fix compilation error with DEBUG_STACK_FRAMES defined, patch by Filipe ↵Johnny Chen2011-08-251-4/+3
| | | | | | | | Cabecinhas! With some slight modification. llvm-svn: 138563
* Centralized a lot of the status information for processes,Greg Clayton2011-04-181-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
* Order of initialization lists.Stephen Wilson2011-04-111-2/+2
| | | | | | | | This patch fixes all of the warnings due to unordered initialization lists. Patch by Marco Minutoli. llvm-svn: 129290
* Add GetFrameWithStackID to the StackFrameList and the Thread (which routes ↵Jim Ingham2011-03-311-0/+15
| | | | | | to its StackFrameList.) llvm-svn: 128592
* Fixed issues with RegisterContext classes and the subclasses. There wasGreg Clayton2011-01-061-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
* There are now to new "settings set" variables that live in each debuggerGreg Clayton2010-10-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
* Add GetSP to the StackFrame.Jim Ingham2010-09-231-0/+20
| | | | llvm-svn: 114674
* Added more API to lldb::SBBlock to allow getting the blockGreg Clayton2010-09-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
* Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope.Greg Clayton2010-09-031-14/+118
| | | | | | | | | 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
* Added a new bool parameter to many of the DumpStopContext() methods that Greg Clayton2010-09-021-1/+1
| | | | | | | | | | | | | | | | | might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path. Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called. Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack. llvm-svn: 112867
* Clarified the intent of the SymbolContextScope class in the headerGreg Clayton2010-08-301-75/+80
| | | | | | | | | | | | | documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
* Made it so we update the current frames from the previous frames by doing STLGreg Clayton2010-08-271-17/+10
| | | | | | | | swaps on the variable list, value object list, and disassembly. This avoids us having to try and update frame indexes and other things that were getting out of sync. llvm-svn: 112301
* Simplified the StackFrameList class down to a single frames list againGreg Clayton2010-08-271-198/+240
| | | | | | | | | | | | | instead of trying to maintain the real frame list (unwind frames) and an inline frame list. The information is cheap to produce when we already have looked up a block and was making stack frame uniquing difficult when trying to use the previous stack when making the current stack. We now maintain the previous value object lists for common frames between a previous and current frames so we will be able to tell when variable values change. llvm-svn: 112277
* Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to ↵Jim Ingham2010-08-261-10/+10
| | | | | | "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
* Cleaned up the inline stack frame code one more time to prepare for inlinedGreg Clayton2010-08-261-123/+142
| | | | | | | | | | code stepping. Also we now store the stack frames for the current and previous stops in the thread in std::auto_ptr objects. When we create a thread stack frame list we pass the previous frame into it so it can re-use the frames and maintain will allow for variable changes to be detected. I will implement the stack frame reuse next. llvm-svn: 112152
* Cleaned up the inline backtrace code even more by moving all stack backtracingGreg Clayton2010-08-251-28/+245
| | | | | | | | functionality into StackFrameList. This will allow us to copy the previous stack backtrace from the previous stop into another variable so we can re-use as much as possible from the previous stack backtrace. llvm-svn: 112007
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+135
llvm-svn: 105619
OpenPOWER on IntegriCloud