summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBSourceManager.cpp
Commit message (Collapse)AuthorAgeFilesLines
* <rdar://problem/13443931>Greg Clayton2013-03-191-23/+33
| | | | | | | | Fixed a crasher in the SourceManager where it wasn't checking the m_target member variable for NULL. In doing this fix, I hardened this class to have weak pointers to the debugger and target in case they do go away. I also changed SBSourceManager to hold onto weak pointers to the debugger and target so they don't keep objects alive by holding a strong reference to them. llvm-svn: 177365
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* SBFrame is now threadsafe using some extra tricks. One issue is that stackGreg Clayton2012-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
* Minor format update (no semantic change).Johnny Chen2011-12-201-2/+2
| | | | llvm-svn: 146930
* Fix regression of test SourceManagerTestCase.test_display_source_python.Johnny Chen2011-10-031-1/+1
| | | | llvm-svn: 141021
* Removed lldb::SBSourceManager_impl. We export everything in the lldb namespaceGreg Clayton2011-10-011-64/+64
| | | | | | | and this implemenation that backs our lldb::SBSourceManager should not be exported. llvm-svn: 140930
* SBSourceManager now gets the real source manager either from the Debugger or ↵Jim Ingham2011-09-131-23/+85
| | | | | | | | Target. Also, move the SourceManager file cache into the debugger so it can be shared amongst the targets. llvm-svn: 139564
* Move the SourceManager from the Debugger to the Target. That way it can ↵Jim Ingham2011-09-081-2/+1
| | | | | | | | | | 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
* Fixed the SymbolContext::DumpStopContext() to correctly indent and dumpGreg Clayton2011-04-231-1/+2
| | | | | | | | | | | | | | | | | inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
* Add test_display_source_python() test case to TestSourceManager.py which usesJohnny Chen2010-12-111-6/+4
| | | | | | | | | | the lldb PyThon API SBSourceManager to display source files. To accomodate this, the C++ SBSourceManager API has been changed to take an lldb::SBStream as the destination for display of source lines. Modify SBStream::ctor() so that its opaque pointer is initialized with an StreamString instance. llvm-svn: 121605
* Added copy constructors and assignment operators to all lldb::SB* classesGreg Clayton2010-11-051-14/+23
| | | | | | so we don't end up with weak exports with some compilers. llvm-svn: 118312
* Very large changes that were needed in order to allow multiple connectionsGreg Clayton2010-06-231-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger. To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack So now clients should call: SBDebugger::Initialize(); // (static function) SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true); // main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached. Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments. llvm-svn: 106615
* And some more include line fixes.Eli Friedman2010-06-091-1/+1
| | | | llvm-svn: 105704
* Initial checkin of lldb code from internal Apple repo.Chris Lattner2010-06-081-0/+65
llvm-svn: 105619
OpenPOWER on IntegriCloud