The attached patch adds eValueTypeVector to lldb_private::Value.  The nested struct Vector is patterned after RegisterValue::m_data.buffer.  This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue.  Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
 
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py.  In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully.  On the other hand, the output is glaringly empty:
    runCmd: expr $xmm0
    output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
    Expecting sub string: vector_type
    Matched

llvm-svn: 167033

Removing the IsDynamic() and GetStaticValue() calls, so that they will default to the base class behavior:
 - non-dynamic
 - itself as the static value
This is in contrast with the previous behavior which could be confusing and could potentially cause issues when using those objects

llvm-svn: 166857

Reimplementing SBValue/ValueObject.GetValueAsUnsigned() in terms of appropriate calls in Scalar - Making sure Scalar does the right thing when casting signed values to unsigned ones.

llvm-svn: 166618

llvm-svn: 166462

Added a new API call to help efficiently determine if a SBValue could have children:

     bool
     SBValue::MightHaveChildren ();
     
This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive.

llvm-svn: 166460

Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)

llvm-svn: 166426

llvm-svn: 166133

<rdar://problem/12503640> Fixing an issue where the dynamic type of an Objective-C pointer changed but we still reported the one-true-definition for the previous type. This was causing issues where a variable could be reported as being of an entirely different type after an assignment

llvm-svn: 166119

Dynamic type code must be efficient and fast. Now it is.

Added ObjC v1 support for getting the complete list of ISA values.

The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.

Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.

llvm-svn: 165730

<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray

llvm-svn: 163818

Added a fix for incorrect dynamic typing. Before when asking if a C++ class could be dynamic, we would answer yes for incomplete C++ classes. This turned out to have issues where if a class was not virtual, yet had its first ivar be an instance of a virtual class, we would incorrectly say that a class was virtual and we would downcast it to be a pointer to the first ivar. We now ask the class to complete itself prior to answering the question. We need to test the effects on memory of this change prior to submission. It is the safest and best fix, but it does have a potential downside of higher memory consumption.

llvm-svn: 163014

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/10449092> Adding a new uppercase hex format specifier. This commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name.

llvm-svn: 161606

llvm-svn: 161592

Fixing an issue where ValueObject::GetPointeeData() would not work correctly for file addresses when fetching items other than the 0-th

llvm-svn: 161384

<rdar://problem/11846023> Fixing a bug where malformed DWARF could lead to an endless recursion with synthetic children

llvm-svn: 161185

llvm-svn: 160338

Fix confusing error message about "expression did not evaluate to an address" when doing 'watchpoint set expression".
Instead of using 0 as the fail_value when invoking ValueObject::GetValueAsUnsigned(), modify the API to take an addition
bool pointer (defaults to NULL) to indicate success/failure of value conversion.

llvm-svn: 158016

<rdar://problem/11355592> Fixing a bug where we would incorrectly try and determine a dynamic type for a variable of a pointer type that is not a valid generic type for dynamic pointers.

llvm-svn: 157190

DataVisualization.h / DataVisualization.cpp / ValueObject.cpp
and
FormatManager.h / FormatManager.cpp

llvm-svn: 156886

<rdar://problem/11239650> Fixing a bug where the SetValueFromCString() method failed to operate on dynamic values. The fix consists in making the set operation fall through to the parent. We only actually allow this if the dynamic value is at a 0-offset from the parent, or the new value is 0. Other scenarios would need agreement on the actual meaning of the set operation (do we keep offsetting? do we just assume the user knows what they are doing?) so we prevent them, and let the expression parser deal with the complexity

llvm-svn: 156422

llvm-svn: 156397

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

llvm-svn: 154028

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

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

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

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

llvm-svn: 153266

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

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

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

Fixing an issue where a ValueObject had changed its value but the 'value changed' flag was not being set. This was breaking one of our test cases

llvm-svn: 152161

fixed a few potential NULL-pointer derefs in ValueObject
we have a way to provide docstrings for properties we add to the SWIG layer - a few of these properties have a docstring already, more will come in future commits
added a new bunch of properties to SBData to make it more natural and Python-like to access the data they contain

llvm-svn: 151962

1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data
2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final
3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around
   this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments
   were treated in a special way and passed in directly instead of through the Options class
4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string
   and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject
5) removing the option to have formats and summaries stick to a variable for the current stoppoint
   after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo
   the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime
   we are open to suggestions on what feels "natural" in this regard

llvm-svn: 151801

 a) adds a Python summary provider for NSDate
 b) changes the initialization for ScriptInterpreter so that we are not passing a bulk of Python-specific function pointers around
 c) provides a new ScriptInterpreterObject class that allows for ref-count safe wrapping of scripting objects on the C++ side
 d) contains much needed performance improvements:
    1) the pointer to the Python function generating a scripted summary is now cached instead of looked up every time
    2) redundant memory reads in the Python ObjC runtime wrapper are eliminated
    3) summaries now use the m_summary_str in ValueObject to store their data instead of passing around ( == copying) an std::string object
 e) contains other minor fixes, such as adding descriptive error messages for some cases of summary generation failure

llvm-svn: 151703

Fixed an error where if we tried to format a ValueObject using a format
that was incorrect for a variable, then it would set ValueObject::m_error
to an error state and stop the value from being able to be updated. We now
leave m_error alone and only let the update value code change that. Any errors
in formatting will return a valid value as C string that contains an error 
string. This lets us then modify the format and redisplay without any issues.

llvm-svn: 151581

I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had 
lldb_private::Section pointers into modules that had been removed or 
replaced. This also let to grabbing stale modules from those sections. 
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *. 

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed. 

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.

llvm-svn: 151336

Objective-C classes.  This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).

This involved the following main changes:

- The ObjCLanguageRuntime now knows how to hunt
  for the authoritative version of an Objective-C
  type.  It looks for the symbol indicating a
  definition, and then gets the type from the
  module containing that symbol.

- ValueObjects now report their type with a
  potential override, and the override is set if
  the type of the ValueObject is an Objective-C
  class or pointer type that is defined somewhere
  other than the original reported type.  This
  means that "frame variable" will always use the
  complete type if one is available.

- The ClangASTSource now looks for the complete
  type when looking for ivars.  This means that
  "expr" will always use the complete type if one
  is available.

- I added a testcase that verifies that both
  "frame variable" and "expr" work.

llvm-svn: 151214

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