summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/Debugger.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Converting ScanFormatDescriptor to use std::string instead of a manually ↵Enrico Granata2013-05-061-24/+29
| | | | | | managed buffer of bytes llvm-svn: 181218
* fix a couple of clang static analyzer warnings.Jason Molenda2013-05-041-1/+1
| | | | | | | Most important was a new[] + delete mismatch in ScanFormatDescriptor() and a couple of possible memory leaks in FileSpec::EnumerateDirectory(). llvm-svn: 181080
* <rdar://problem/13700260>Greg Clayton2013-05-011-0/+5
| | | | | | | | | | | | | | <rdar://problem/13723772> Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves. A few things are introduced: - lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread. - Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification. - Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them - Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation. llvm-svn: 180886
* <rdar://problem/13209140>Enrico Granata2013-04-241-2/+15
| | | | | | “plugin load” tries to be more helpful when it fails to load a plugin llvm-svn: 180218
* <rdar://problem/13449987>Greg Clayton2013-04-041-0/+2
| | | | | | Show thread name and dispatch queue by default in the thread display. llvm-svn: 178790
* <rdar://problem/13521159>Greg Clayton2013-03-271-4/+4
| | | | | | | | 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
* Our commands that end up displaying a ValueObject as part of their workflow ↵Enrico Granata2013-03-261-2/+1
| | | | | | | | | | | use OptionGroupValueObjectDisplay as their currency for deciding the final representation ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code This checkin provides one and only one (and hopefully correct :-) entry point for this conversion llvm-svn: 178044
* <rdar://problem/13502196> Greg Clayton2013-03-261-1/+10
| | | | | | Functions in "(anonymous namespace)" was causing LLDB to crash when trying to complete a type and it would also cause functions arguments to appear in wrong place in frame display when showing function arguments. llvm-svn: 177965
* <rdar://problem/13498879> Greg Clayton2013-03-251-9/+2
| | | | | | C String summary is emitting "<invalid usage of pointer value as object>" for bad pointers. Now it doesn't emit anything. llvm-svn: 177913
* <rdar://problem/13443931>Greg Clayton2013-03-191-1/+10
| | | | | | | | 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
* Call Process::Finalize directly in Debugger::Destroy, rather than having it ↵Jim Ingham2013-02-271-4/+1
| | | | | | | | | | | done in the Process destructor. Doing it there can be too late depending on what the internal state and ProcessGDBRemote Async threads are doing. <rdar://problem/13297536> llvm-svn: 176203
* Moving from std::auto_ptr<char> to std::string for simple string memory ↵Enrico Granata2013-02-011-11/+10
| | | | | | | | management. It is better practice and, also, it is not clear whether std::auto_ptr<> is smart enough to know about delete[] vs. delete llvm-svn: 174236
* <rdar://problem/12978143>Enrico Granata2013-01-281-2/+2
| | | | | | | | | | | Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
* <rdar://problem/13069948>Greg Clayton2013-01-251-7/+6
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* <rdar://problem/12953853>Greg Clayton2013-01-081-3/+3
| | | | | | | | | | Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file. Also fixed issues in the test suite that arose after fixing the bug. Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option. llvm-svn: 171816
* <rdar://problem/11844604>Greg Clayton2012-12-101-4/+4
| | | | | | When displaying function.name-with-args format will now print "varname=<unavailable>" instead of omitting argument names and values when there is an error reading the value. llvm-svn: 169781
* <rdar://problem/12560257>Greg Clayton2012-12-061-1/+1
| | | | | | Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure. llvm-svn: 169465
* 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
* Save and restore terminal state when lldb is suspended with SIGTSTP and ↵Jim Ingham2012-11-301-1/+20
| | | | | | | | | resumed with SIGCONT. Readline & gdb have a bunch of code to handle older UNIX'es with other job control mechanisms. I didn't try to replicate that. llvm-svn: 169032
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-11/+11
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* <rdar://problem/11449953> Change Debugger::SetOutputFileHandle() so that it ↵Enrico Granata2012-10-291-1/+6
| | | | | | | | | does not automatically initialize the script interpreter in order to transfer its output file handle to it This should delay initialization of Python until strictly necessary and speed-up debugger startup Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes llvm-svn: 166967
* Added the infrastructure necessary for plug-ins to be able to add their own ↵Greg Clayton2012-10-191-1/+5
| | | | | | | | | | | | | | | | | settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at: plugin dynamic-loader macosx-kernel (bool) disable-kext-loading To settings can be set using: (lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins. llvm-svn: 166294
* Improvements to the data formatters logging - plus, new log messages when ↵Enrico Granata2012-10-171-30/+30
| | | | | | our dynamic type changes llvm-svn: 166133
* Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two ↵Jim Ingham2012-10-161-2/+2
| | | | | | | | breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000
* Implementing plugins that provide commands.Enrico Granata2012-09-281-0/+107
| | | | | | | | | | | | | | | | | | | This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin. Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands Caveats: Currently, the new API objects and features are not exposed via Python. The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object) There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own llvm-svn: 164865
* Fixed an error with a static enum definition where it wasn't NULL terminate ↵Greg Clayton2012-09-131-0/+1
| | | | | | and could crash. llvm-svn: 163851
* Made it so changes to the prompt via "settings set prompt" get noticed by ↵Greg Clayton2012-09-011-1/+22
| | | | | | | | | | the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+5
| | | | | | | | | | | | Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
* <rdar://problem/12022079>Greg Clayton2012-08-231-14/+21
| | | | | | | | | | | | | | | | | | | | Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
* Remove further outdated "settings" code and also implement a few missing things.Greg Clayton2012-08-221-923/+17
| | | | llvm-svn: 162376
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-221-560/+1100
| | | | | | | | | | | | | issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
* Turn on function args by default in thread & frame formats.Jim Ingham2012-08-091-1/+1
| | | | | | <rdar://problem/11703715> llvm-svn: 161611
* LLDB no longer prints <no result> by default ifSean Callanan2012-08-091-1/+20
| | | | | | | | | | | the expression returns nothing. There is now a setting, "notify-void." When the user enables that setting, lldb prints (void) if an expression's result is void. Otherwise, lldb is silent. <rdar://problem/11225150> llvm-svn: 161600
* Removed explicit NULL checks for shared pointersSean Callanan2012-08-091-1/+1
| | | | | | | | | and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-4/+4
| | | | llvm-svn: 160338
* <rdar://problem/11870357>Greg Clayton2012-07-141-42/+0
| | | | | | Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
* <rdar://problem/11852100>Greg Clayton2012-07-111-4/+4
| | | | | | The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
* <rdar://problem/11246147>Greg Clayton2012-05-161-2/+8
| | | | | | Make sure our debugger STDIN read thread shuts down quickly when we are done with it. We had a case where the owner of the file handle was not closing it and caused spins. llvm-svn: 156879
* <rdar://problem/11338654> Fixing a bug where having a summary for a bitfield ↵Enrico Granata2012-05-081-1/+18
| | | | | | without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
* Don't call SBDebugger::SetInternalVariable in the sigwinch_handler, since ↵Jim Ingham2012-04-261-4/+12
| | | | | | | | | | | that takes locks and potentially does allocations. Just call SBDebugger::SetTerminalWidth on the driver's SBDebugger, which does the same job, but no locks. Also add the value checking to SetTerminalWidth you get with SetInternalVariable(..., "term-width", ...). rdar://problem/11310563 llvm-svn: 155665
* <rdar://problem/11148044>Greg Clayton2012-03-301-49/+67
| | | | | | Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
* Synthetic values are now automatically enabled and active by default. ↵Enrico Granata2012-03-271-1/+2
| | | | | | | | | | | | SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
* Massive enumeration name changes: a number of enums in ValueObject were not ↵Enrico Granata2012-03-191-25/+28
| | | | | | | | | | | | | | | | | | following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
* <rdar://problem/10997402>Greg Clayton2012-03-071-2/+2
| | | | | | | | | | | 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
* Make Debugger::SetLoggingCallback public, and expose it through the SB API. ↵Jim Ingham2012-02-221-3/+3
| | | | | | | | Sometimes it is not convenient to provide a log callback right when the debugger is created. llvm-svn: 151209
* Add a logging mode that takes a callback and flush'es to that callback.Jim Ingham2012-02-211-3/+76
| | | | | | Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
* 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
* Add a general mechanism to wait on the debugger for Broadcasters of a given ↵Jim Ingham2012-02-161-1/+2
| | | | | | | | | class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
* <rdar://problem/10062621>Enrico Granata2012-02-151-0/+21
| | | | | | | | | | | | | | | | | | New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
* SBFrame is now threadsafe using some extra tricks. One issue is that stackGreg Clayton2012-01-301-19/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud