- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
   a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
   in frozen objects ; now such reads transparently move from host to target as required
 - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
   removed code that enabled to recognize an expression result VO as such
 - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
   representing a T* or T[], and doing dereferences transparently
   in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
 - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
   en lieu of doing the raw read itself
 - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
   this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
   in public layer this returns an SBData, just like GetPointeeData()
 - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
   the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
   of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
 - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
 of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
 addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types

llvm-svn: 139160

register names when dumping variable locations and location lists. Also did
some cleanup where "int" types were being used for "lldb::RegisterKind"
values.

llvm-svn: 138988

a data using DataEncoder.

Added DataEncoder to the lldb-forward.h file.

llvm-svn: 138950

can reserve a block of memory and store stuff into it.

llvm-svn: 138949

llvm-svn: 138678

currently selected thread.  And update the call sites accordingly.

llvm-svn: 138577

llvm-svn: 138565

Renamed format "signed decimal" to be "decimal". "unsigned decimal" remains unchanged:
 - the name "signed decimal" was interfering with symbol %S (use summary) in summary strings.
   because of the way summary strings are implemented, this did not really lead to a bug, but
   simply to performing more steps than necessary to display a summary. this is fixed.
Documentation improvements (more on synthetic children, some information on filters). This is still a WIP.

llvm-svn: 138384

Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite

llvm-svn: 138315

Separated FormatNavigator and FormatManager in two different files ; moved FormatCategoryItem enum out of FormatManager.h as a debugger-wide lldb_private enum ; minor style cleanups

llvm-svn: 138307

More cleanups ; Separated implementation of FormatManager from class DataVisualization as a front-end by using separate .h/.cpp files - Final aim is to break up FormatManager.h/cpp into several separate files

llvm-svn: 138279

 - FormatCategories now are directly mapped by ConstString objects instead of going through
   const char* -> ConstString -> const char*
 - FormatCategory callback does not pass category name anymore. This is not necessary because
   FormatCategory objects themselves hold their name as a member variable

llvm-svn: 138254

  If you have a Python module foo, in order to use its contained objects in LLDB you do not need to use
  'from foo import *'. You can use 'import foo', and then refer to items in foo as 'foo.bar', and LLDB
  will know how to resolve bar as a member of foo.
  Accordingly, GNU libstdc++ formatters have been moved from the global namespace to gnu_libstdcpp and a few
  test cases are also updated to reflect the new convention. Python docs suggest using a plain 'import' en lieu of
  'from-import'.

llvm-svn: 138244

plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable 
themselves when the right binary/target triple are being debugged. The 
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object 
pointer which can be inspected to see if the main executable, target triple,
or any shared  libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.

llvm-svn: 138228

it, it could try and call through to an installed callback.

llvm-svn: 138146

- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error
  e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class"
- Added a new special formatting token %T for summaries. This shows the type of the object.
  Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L}
- Bits and pieces required to support "frame variable array[n-m]"
  The feature is not enabled yet because some additional design and support code is required, but the basics
  are getting there
- Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP
  Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for
  a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd

llvm-svn: 138080

 - reorganizing the PTS (Partial Template Specializations) in FormatManager.h
 - applied a patch by Filipe Cabecinhas to make LLDB compile with GCC
Functional changes:
 - fixed an issue where command type summary add for type "struct Foo" would not match any types.
   currently, "struct" will be stripped off and type "Foo" will be matched.
   similar behavior occurs for class, enum and union specifiers.

llvm-svn: 138020

 - reorganizing classes layout to have public part first
   Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception
 - avoiding methods in the form T foo() { code; } all on one-line
 - moving method implementations from .h to .cpp whenever feasible
   Templatized code is an exception and so are very small methods
 - generally, adhering to coding conventions followed project-wide
Functional changes:
 - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed
   The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer
   Accordingly fixed test cases and added a new test case

llvm-svn: 137944

 - all instances of "vobj" have been renamed to "valobj"
 - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp)
   The interface to this class has not changed
 - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting
   from ConstString to const char* and back all the time
   Next step is making the same happen for categories themselves
 - category gnu-libstdc++ is defined in the constructor for a FormatManager
   The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time
   All references to previous 'osxcpp' name have been removed from both code and file names
Functional changes:
 - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string
   to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script
   will become -o

llvm-svn: 137886

New category "gnu-libstdc++" provides summary for std::string and synthetic children for types std::map, std::list and std::vector
 The category is enabled by default. If you run into issues with it, disable it and the previous behavior of LLDB is restored
 ** This is a temporary solution. The general solution to having formatters pulled in at startup should involve going through the Platform.
Fixed an issue in type synthetic list where a category with synthetic providers in it was not shown if all the providers were regex-based

llvm-svn: 137850

and signed integers.

llvm-svn: 137710

processor; we may get this subtype ("CPU_SUBTYPE_X86_ARCH1") back
when starting a kdp session.

llvm-svn: 137701

location was in a register would not be able to dereference 
children when displaying "*var" or the derefence of the variable.

llvm-svn: 137695

llvm-svn: 137630

to keep GCC 4.5.2 happy and also to not use a deprecated
llvm API.

llvm-svn: 137605

any integers that are larger than a 8 bytes. We can now
display signed decimal, unsigned decimal, octal, and binary
(we could already view hex before this fix).

llvm-svn: 137602

llvm-svn: 137547

Also change the SourceInitFile to look for .lldb-<APPNAME> and source that
preferentially if it exists.
Also made the breakpoint site report its address as well as its breakpoint number
when it gets hit and can't find any the associated locations (usually because the
breakpoint got disabled or deleted programmatically between the time it was hit
and reported.)
Changed ThreadPlanCallFunction to initialize the ivar m_func in the initializers of the
constructor, rather than waiting to initialize till later on in the function.
Fixed a bug where if you make an SBError and the ask it Success, it returns false.
Fixed ValueObject::ResolveValue so that it resolves a temporary value, rather than
overwriting the one in the value object.

llvm-svn: 137536

llvm-svn: 137534

cause extra shared pointer references to one or more modules to be leaked.
This would cause many object files to stay around the life of LLDB, so after
a recompile and rexecution, we would keep adding more and more memory. After
fixing the leak, we found many cases where leaked stack frames were still
being used and causing crashes in the test suite. These are now all resolved.

llvm-svn: 137516

Added an error message when the user tries to add a filter when a synthetic provider for the same type is already defined in the same category
The converse is also true: an error is shown when the user tries to add a synthetic provider to a category that already has a filter for the same type

llvm-svn: 137493

llvm-svn: 137462

*New setting target.max-children-count gives an upper-bound to the number of child objects that will be displayed at each depth-level
  This might be a breaking change in some scenarios. To override the new limit you can use the --show-all-children (-A) option
  to frame variable or increase the limit in your lldbinit file
*Command "type synthetic" has been split in two:
  - "type synthetic" now only handles Python synthetic children providers
  - the new command "type filter" handles filters
  Because filters and synthetic providers are both ways to replace the children of a ValueObject, only one can be effective at any given time.

llvm-svn: 137416

llvm-svn: 137407

llvm-svn: 137374

llvm-svn: 137334

llvm-svn: 137328

Access to synthetic children by name:
 if your object has a synthetic child named foo you can now type
  frame variable object.foo (or ->foo if you have a pointer)
  and that will print the value of the synthetic child
  (if your object has an actual child named foo, the actual child prevails!)
 this behavior should also work in summaries, and you should be able to use
 ${var.foo} and ${svar.foo} interchangeably
  (but using svar.foo will mask an actual child named foo)

llvm-svn: 137314

llvm-svn: 137300

This is helping us track down some extra references to ModuleSP objects that
are causing things to get kept around for too long. 

Added a module pointer accessor to target and change a lot of code to use 
it where it would be more efficient.

"taret delete" can now specify "--clean=1" which will cleanup the global module
list for any orphaned module in the shared module cache which can save memory
and also help track down module reference leaks like we have now.

llvm-svn: 137294