Automatically enabling the Cocoa formatter categories for command-line LLDB. Previously, the categories were filled in but disabled by default. Tweaking test cases appropriately to keep working and do the right thing

llvm-svn: 155605

Returning data formatters to their previous working condition - Plus fixing an issue that was preventing Python oneliners from executing

llvm-svn: 155563

Fixing an issue where the expression parser was not correctly freeze-drying bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise

llvm-svn: 155494

This patch fixes a bug where LLDB was incorrectly setting the address-size on a DataExtractor to be sizeof(void*) when the ValueObject came out of the expression parser
This worked correctly for 64-bit targets, but broke down data formatters in i386 mode. The formatters would try to read pointers out of the frozen-dried objects,
but were unable to do so because they would try fetching 8 bytes from a DataExtractor with only 4 bytes in it. This patch fixes the issue by always making the pointer-size
for a DataExtractor match the target setting.

llvm-svn: 155418

Added the ability to log a message with a backtrace when verbose logging is enabled to the Module class. Used this new function in the DWARF parser.

llvm-svn: 155404

Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index.

llvm-svn: 155398

Don't put the address of the module in the module basename as this hoses up our ability to find shared libraries by name. We now put it into the Module object name.

llvm-svn: 155223

llvm-svn: 154535

Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.

Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.

llvm-svn: 154458

Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.

llvm-svn: 154339

Fixed ModuleList::FindTypes() so that when a symbol context is supplied that contains a valid module, it will search that module first, then if we are still looking for matches (we have found less that "max_matches"), search in all of the other modules as well.

llvm-svn: 154186

In a prior commit, I changed the parameters around on a ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit.

llvm-svn: 154182

llvm-svn: 154055

llvm-svn: 154028

Fixed a potential crasher that could happen after Debugger::Terminate() was called.

llvm-svn: 153774

ValueObject, and make sure that ValueObjects that
have null type names (because they have null types)
also have null qualified type names.  This avoids
some potential crashes if 
ValueObject::GetQualifiedTypeName tries to get the
name of their type by calling GetClangTypeImpl().

llvm-svn: 153718

llvm-svn: 153683

Fixing an issue where Unicode characters in an NSString were printed as escape sequences by the summary provider shipping with LLDB - Added relevant test case code. Bonus points for identifying the source of the quotes :-)

llvm-svn: 153624

llvm-svn: 153541

indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.

lldb_private::Section now has:

bool
Section::IsThreadSpecific () const
{
    return m_thread_specific;
}

void
Section::SetIsThreadSpecific (bool b)
{
    m_thread_specific = b;
}

The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"
sections.

Eventually we need to have each lldb_private::Thread subclass be able to 
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.

llvm-svn: 153537

Synthetic values are now automatically enabled and active by default. 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

Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482

This is the feature that allowed the user to have things like:

class Base { ... };
class Derived : public Base { ... };

and have formatters defined for Base work automatically for Derived.

This feature turned out to be too expensive since it requires completing types.

This patch takes care of removing cascading (other than typedefs chain cascading), updating the test suite accordingly, and adding required Cocoa class names to keep the AppKit formatters working

llvm-svn: 153272

when using the "frame variable" or "target variable" commands.

llvm-svn: 153266

the migration to ModuleSpec objects this broke and is now fixed.

Also fixed a case in the darwin kernel dynamic loader where we just need to
trust the load address of the kernel if we can't read it from memory.

llvm-svn: 153164

llvm-svn: 153113

llvm-svn: 153106

llvm-svn: 153101

llvm-svn: 153076

Massive enumeration name changes: a number of enums in ValueObject were not 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

Fixed a case where the source path remappings on the module were too expensive to
use when we try to verify (stat the file system) that the remapped path points to
a valid file. Now we will use the lldb_private::Module path remappings (if any) when
parsing the debug info without verifying that the paths exist so we don't slow down
line table parsing speeds.

llvm-svn: 153059

Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available.

llvm-svn: 152836

The Cocoa formatters now provide error messages for many of the common things-went-wrong situations. Previously they would say nothing or log failures to the Python console

llvm-svn: 152673

llvm-svn: 152599

Changed several of the Cocoa formatters to match the output style that Xcode uses internally to provide summaries
This has been done for those summaries where the difference is only cosmetic (e.g. naming things as items instead of values, ...)
The LLDB output style has been preserved when it provides more information (e.g. telling the type as well as the value of an NSNumber)

Test cases have been updated to reflect the updated output style where necessary

llvm-svn: 152592

 std::string has a summary provider
 std::vector std::list and std::map have both a summary and a synthetic children provider
Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two
The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic)

The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because
 (a) we need different compiler flags for libc++ than for libstdcpp
 (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference

llvm-svn: 152570

Don't show variable values in Xcode when they are out of scope. This allows Xcode to step a lot faster when there are many variables in the variables view.

llvm-svn: 152380

<rdar://problem/10975912>

llvm-svn: 152376

Changed ValueObject to use a dedicated ChildrenManager class to store its children, instead of an std::vector
This solves an issue where a ValueObject was getting a wrong children count (usually, a huge value) and trying to resize the vector of children to fit that many ValueObject*

Added a loop detection algorithm to the synthetic children provider for std::list

Added a few more checks to the synthetic children provider for std::vector

Both std::list and std::vector's synthetic children providers now cache the count of children instead of recomputing it every time
std::map has a field that stores the count, so there is little need to cache it on our side

llvm-svn: 152371

shouldn't compile any of the XPC support code.  

Update macosx/Host.mm to use that define.

Add a LLDB_DISABLE_PYTHON ifdef block around a new function in 
Core/FormatManager.cpp.

<rdar://problem/10942125>

llvm-svn: 152293