Cleanup some variable names to indicate auto pointers and also manager the llvm::Module memory more correctly.

llvm-svn: 166598

There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename."  It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.

I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.

<rdar://problem/12559915>

llvm-svn: 166533

Objective C cleanup. Removed an cache that was no longer needed and changes the code that gets the dynamic type and class name to use our new Objective C cache.

llvm-svn: 166512

Adding the new has_children (or MightHaveChildren() in C++) for the existing synthetic children providers
In a few cases, the new call is going to be much more efficient than the previous num_children > 0 check
When the optimization was marginal (e.g. std::vector<>), the choice was to use num_children in order to keep
implementation details in one function instead of duplicating code

Next step is to provide test cases

llvm-svn: 166506

llvm-svn: 166502

This commit enables the new HasChildren() feature for synthetic children providers
Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call
Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly

Next steps are:
2) writing smart implementations of has_children for our providers whenever possible
3) make a test case

llvm-svn: 166495

it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.  

llvm-svn: 166472

the function's prologue instructions so we can re-instate that prologue
if we hit an early return mid-function.  Add some additional heuristics
to differentiate between prologue and epilogue instruction sequences.

This fixes the specific problem of correctly unwinding through a function
which has an epilogue one instruction after the last prologue setup
instruction has completed.
<rdar://problem/12091139> 

llvm-svn: 166465

llvm-svn: 166464

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

options:

- added help ("help language") listing the
  possible options;

- added the possibility of synonyms for language
  names, in this case "ObjC" for "Objective-C";
  and

- made matching against language names case
  insensitive.

This should improve discoverability.

<rdar://problem/12552359>

llvm-svn: 166457

of structures, and added a testcase.

<rdar://problem/12551591>

llvm-svn: 166450

Fixed a crasher where if an invalid SBTarget was passed to:

lldb::addr_t
SBAddress::GetLoadAddress (const SBTarget &target) const;

We would crash.

llvm-svn: 166439

<rdar://problem/12479701> Use the plain pydoc pager to work around Python help() pagination conflicts with our I/O management

llvm-svn: 166432

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

Allow type searches to specify a type keyword when searching for type. Currently supported type keywords are: struct, class, union, enum, and typedef.

So now you can search for types with a string like "struct foo".

llvm-svn: 166420

to be printed truncated.

<rdar://problem/12389615>

llvm-svn: 166368

the header file.
(followup patch to Sean's commit of r166355 earlier today.)

llvm-svn: 166365

and attaching APIs.

llvm-svn: 166356

- Fixed a crash when the executable module
  couldn't be found.
- Fixed a problem that made it impossible
  to attach to processes in the simulator
  using the SBTarget::Attach.

llvm-svn: 166355

Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header.

An example of sending a read register packet for the GPR on x86_64:

(lldb) process plugin packet send --command 0x07 --payload 0100000004000000

llvm-svn: 166346

Change the name of the variable used to detect if we are loading kexts to "load-kexts" instead of "disable-kext-loading" since the value is a boolean. This was requested by the person who requested the feature. It now defaults to true:

(lldb) settings show plugin.dynamic-loader.darwin-kernel.load-kexts
plugin.dynamic-loader.darwin-kernel.load-kexts (boolean) = true

llvm-svn: 166315

Rename "macosx-kernel" to "darwin-kernel" to match the filenames before anyone starts using the settings for this plug-in.

llvm-svn: 166295

Added the infrastructure necessary for plug-ins to be able to add their own 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

in a kernel debug session:

settings set target.disable-kext-loading true

<rdar://problem/12490623>

llvm-svn: 166262

instead of asciified bytes.  <rdar://problem/12522978>

llvm-svn: 166258

1 by the expression parser.  We now correctly
report that they are of size 0.  (C++ structs
are mandated to have nonzero size, and Clang marks
them as being 1 byte in size.)

<rdar://problem/12380800>

llvm-svn: 166256

Change the "rb" alias to "rbreak" since some people are used to typing more than "rb" and so weren't 
finding the alias.

llvm-svn: 166249

Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:

settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py

Then run your program and see the extra threads. 

llvm-svn: 166244

<rdar://problem/12068650>

More fixes to how we handle paths that are used to create a target.

This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".

llvm-svn: 166186

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) = 

There is also the program argument that are separate from the first argument that have existed for a while:

target.run-args (arguments) =

When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args

Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.

llvm-svn: 166137

llvm-svn: 166133

using a reference-counted pointer.  This avoids
memory-management problems when the TargetOptions
are deleted.

llvm-svn: 166132

the expression parser (also wchar_t) and added a
test case.

llvm-svn: 166131

<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

to handle an addition class of early-return instructions we find in arm code:
tail-call optimziation returns where we restore the register state from the
function entry and jump directly (not branch & link) to another function --
when that other function returns, it will return to our caller.

Previously this mid-function epilogue sequence was not being correctly detected.
We would not re-instate the prologue setup instructions for the rest of the function
so unwinds would break from that point until the end of the function.
<rdar://problem/12502597> 

llvm-svn: 166081

llvm-svn: 166070

the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062

llvm-svn: 166060