summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Forgot to check for empty error strings in the previous checkinEnrico Granata2013-05-201-1/+1
| | | | llvm-svn: 182325
* <rdar://problem/13878726>Enrico Granata2013-05-203-4/+55
| | | | | | | | | | | | | | This changes the setting target.load-script-from-symbol-file to be a ternary enum value: default (the default value) will NOT load the script files but will issue a warning suggesting workarounds yes will load the script files no will not load the script files AND will NOT issue any warning if you change the setting value from default to yes, that will then cause the script files to be loaded (the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it) if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value llvm-svn: 182323
* <rdar://problem/11398407>Greg Clayton2013-05-183-14/+38
| | | | | | | | Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be. This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this. llvm-svn: 182179
* Allow LLDB to be built on a system with an installed gcc/g++ that isn't the ↵Greg Clayton2013-05-171-1/+1
| | | | | | | | | | default. I recently installed gcc-4.7/g++-4.7 on Ubuntu and tried to build by specifying: CC=gcc-4.7 CXX=g++-4.7 as configure and make args, but it didn't work when being run with makefiles. This patch fixes that. llvm-svn: 182158
* Fixed a few obvious errors pointed out by the static analyzer.Jim Ingham2013-05-152-1/+11
| | | | llvm-svn: 181911
* Only include under arm and an Apple system. Otherwise, it will fail under a ↵Sylvestre Ledru2013-05-151-1/+1
| | | | | | GNU/Linux under ARM llvm-svn: 181876
* <rdar://problem/13183720>Enrico Granata2013-05-131-1/+7
| | | | | | | | Provide a mechanism through which users can disable loading the Python scripts from dSYM files This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script") You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load llvm-svn: 181709
* <rdar://problem/13854277>Greg Clayton2013-05-107-130/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* <rdar://problem/13621080>Enrico Granata2013-05-081-11/+7
| | | | | | | | | This commit changes the ${function.name-with-args} prompt keyword to also tackle structs Previously, since aggregates have no values, this would show up as foo=(null) This checkin changes that to instead print foo=(Foo at 0x123) (i.e. typename at address) There are other potential choices here (summary, one-liner printout of all members, ...) and I would love to hear feedback about better options, if any llvm-svn: 181462
* 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
* Remove the UUID::GetAsCString() method which required a buffer to save the Jason Molenda2013-05-032-21/+21
| | | | | | | UUID string in; added UUID::GetAsString() which returns the uuid string in a std::string. Updated callers to use the new method. llvm-svn: 181078
* Don’t use the resolved value to calculate the location unless the variable ↵Enrico Granata2013-05-031-2/+5
| | | | | | | | is in a register This was causing a bunch of test cases to fail in python_api/process since they relied on SBValue::GetLocation() llvm-svn: 181075
* <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
* RegisterValues can now report their contents asSean Callanan2013-04-301-1/+58
| | | | | | | | | | UInts even if their contents were set as bytes. This makes expressions using registers work better, especially with core files. <rdar://problem/13743427> llvm-svn: 180810
* <rdar://problem/13695846>Enrico Granata2013-04-303-9/+101
| | | | | | | | Enabling LLDB to write to variables that are stored in registers Previously, this would not work since the Value's Context loses the notion of the data being in a register We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write llvm-svn: 180803
* Cleanup logging to use the new "std::string FileSpec::GetPath()" function. ↵Greg Clayton2013-04-295-34/+33
| | | | | | | | | | | Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
* <rdar://problem/13565393>Greg Clayton2013-04-251-1/+1
| | | | | | If a register is in a ValueObject, be sure to print its children if it is a vector type. llvm-svn: 180237
* Don't print the type if there is none and don't print "<invalid type>". ↵Greg Clayton2013-04-251-3/+8
| | | | | | | | ValueObjects can be register sets and register groups and dumping those with: (lldb) script print frame.GetRegisters() llvm-svn: 180236
* Added the ability to extract a ModuleSpecList (a new class) from an ↵Greg Clayton2013-04-241-16/+39
| | | | | | | | | | | | | | | | | ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)). There is a new static ObjectFile function you can call: size_t ObjectFile::GetModuleSpecifications (const FileSpec &file, lldb::offset_t file_offset, ModuleSpecList &specs) This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question). This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info. llvm-svn: 180224
* <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
* Fix lock hierarchy violation in Listener/BroadcasterDaniel Malea2013-04-221-0/+3
| | | | | | | - avoid deadlocks if Broadcaster::SignUpListenersForBroadcaster and Listener::StartListeningForEventSpec are both called concurrently llvm-svn: 180050
* Fix data race in Address class by wrapping m_offset in std::atomicDaniel Malea2013-04-221-2/+2
| | | | llvm-svn: 180047
* Fixed some linux buildbot warnings.Greg Clayton2013-04-191-6/+10
| | | | llvm-svn: 179892
* Fixed two problems when reading constant/registerSean Callanan2013-04-191-1/+18
| | | | | | | | | | | | | | variables in the ValueObject code: - Report an error if the variable does not have a valid address. - Return the contents of the data to GetData(), even if the value is constant. <rdar://problem/13690855> llvm-svn: 179876
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-184-7/+7
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-185-8/+17
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* <rdar://problem/13657900>Greg Clayton2013-04-161-0/+21
| | | | | | Special handling for file descriptor connections that are tty files. llvm-svn: 179613
* Added a SetData() method to ValueObject. ThisSean Callanan2013-04-134-0/+199
| | | | | | | | | | | | | | lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
* <rdar://problem/13623698>Enrico Granata2013-04-112-1/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
* Reorder the Platform plugin settings so that they're nowJason Molenda2013-04-051-6/+50
| | | | | | | | | platform.plugin.darwin-kernel.kext-directories platform.plugin.darwin-kernel.search-locally-for-kexts and fix a few FileSpec handling issues for the kext-directories setting. llvm-svn: 178920
* Add support for Platform plugins to have settings.Jason Molenda2013-04-051-9/+67
| | | | | | | | | Add two initial settings for the PlatformDarwinKernel plugin, plugin.platform.darwin-kernel.search-locally-for-kexts [true|false] plugin.platform.darwin-kernel.kext-directories [directory list] llvm-svn: 178846
* <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/13384801>Greg Clayton2013-04-033-58/+47
| | | | | | Make lldb_private::RegularExpression thread safe everywhere. This was done by removing the m_matches array from the lldb_private::RegularExpression class and putting it into the new lldb_private::RegularExpression::Match class. When executing a regular expression you now have the option to create a lldb_private::RegularExpression::Match object and pass a pointer in if you want to get parenthesized matching. If you don't want any matching, you pass in NULL. The lldb_private::RegularExpression::Match object is initialized with the number of matches you desire. Any matching strings are now extracted from the lldb_private::RegularExpression::Match objects. This makes the regular expression objects thread safe and as a result many more regex objects were turned into static objects that end up using a local lldb_private::RegularExpression::Match object when executing. llvm-svn: 178702
* <rdar://problem/13506727> Greg Clayton2013-04-032-29/+197
| | | | | | | | | | | | Symbol table function names should support lookups like symbols with debug info. To fix this I: - Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in - Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much - Filter the results at a higher level - Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name. llvm-svn: 178608
* <rdar://problem/11730263>Greg Clayton2013-03-282-41/+54
| | | | | | | | | | PC relative loads are missing disassembly comments when disassembled in a live process. This issue was because some sections, like __TEXT and __DATA in libobjc.A.dylib, were being moved when they were put into the dyld shared cache. This could also affect any other system that slides sections individually. The solution is to keep track of wether the bytes we will disassemble are from an executable file (file address), or from a live process (load address). We now do the right thing based off of this input in all cases. llvm-svn: 178315
* Introduces extended register sets whose availability can vary with the ↵Ashok Thirumurthi2013-03-281-2/+1
| | | | | | | | | | target processor. - Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable. Thanks to Greg Clayton for his review feedback. llvm-svn: 178252
* <rdar://problem/13521159>Greg Clayton2013-03-2713-59/+59
| | | | | | | | 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
* <rdar://problem/13246939>Enrico Granata2013-03-261-1/+1
| | | | | | Make format uint64_t[] actually work as designed llvm-svn: 178072
* Clean up logging a bit to not log when a command pipe is opened when “lldb ↵Greg Clayton2013-03-261-1/+1
| | | | | | object” logging is on. llvm-svn: 178068
* 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/13365424>Enrico Granata2013-03-251-1/+2
| | | | | | | | | | | | | | | | | Ensure that option -Y also works for expression as it does for frame variable Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value. This is required for scenarios like this to work: (lldb) p/x c (Class) $0 = 0x0000000100adb7f8 NSObject Previously this would say: (lldb) p/x c (Class) $0 = NSObject ignoring the explicit format specifier llvm-svn: 177893
* And then again only compute the more expensive piece of data if need be :-)Enrico Granata2013-03-231-1/+1
| | | | llvm-svn: 177812
* Invert two condition checks to evaluate them in cheapest-to-more-expensive orderEnrico Granata2013-03-231-2/+2
| | | | llvm-svn: 177810
* <rdar://problem/13315663>Enrico Granata2013-03-231-9/+32
| | | | | | | | commands of the form frame variable -f c-string foo where foo is an arbitrary pointer (e.g. void*) now do the right thing, i.e. they deref the pointer and try to get a c-string at the pointed address instead of dumping the pointer bytes as a string. the old behavior is used as a fallback if things don’t go well llvm-svn: 177799
* Only get the script interpreter if we find scripting resources in the symbol ↵Greg Clayton2013-03-231-13/+13
| | | | | | file. This helps us avoid initializing python when it isn't needed. llvm-svn: 177793
* Fix a little fallout from the changes in r174757 where we wouldJason Molenda2013-03-231-9/+0
| | | | | | | | skip every other float/double/long double as we extracted data from a buffer. <rdar://problem/13485062> llvm-svn: 177779
* Fixed the ValidOffsetForDataOfSize() to use simpler logic. Fixed ↵Greg Clayton2013-03-211-26/+0
| | | | | | DataExtractor::BytesLeft() to return the correct value. llvm-svn: 177616
OpenPOWER on IntegriCloud