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

<rdar://problem/12446320> Fixing an issue with our Driver where setting an immediate output would not cause suppression of the final printout. This allows effective output redirection for Python commands

llvm-svn: 166058

to work properly; when doing bare-boards rom debugging
force the OS to be one of those when initializing llvm.
<rdar://problem/12504138>

llvm-svn: 166057

This patch fixes an issue where if lldb fails to attach to a process (ie. invalid pid) on Linux, the process monitor thread gets stuck waiting for a signal from the attach thread, which never comes due to not being signaled. It also implements StopOpThread which is used for both attach/launch cases as I'm not aware of any special handling needed for the attach case. Also, propagate 'Error' from the Detach function instead of using a bool.

llvm-svn: 166055

must push something on the stack for a function call or not.  In
x86, the stack pointer is decremented when the caller's pc is saved
on the stack.  In arm, the stack pointer and frame pointer don't
necessarily have to change for a function call, although most
functions need to use some stack space during their execution.

Use this information in the RegisterContextLLDB to detect invalid 
unwind scenarios more accurately.

<rdar://problem/12348574>

llvm-svn: 166005

Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two breakpoints were set on consecutive addresses, the continue from the 
first breakpoint would skip the second.

llvm-svn: 166000

Added "process plugin packet send" and "process plugin packet history" for GDB remote. "process plugin packet send" will send a packet and receive a response. "process plugin packet history" will dump the packet history buffer.

llvm-svn: 165991

lldb::BasicType
ClangASTContext::GetLLDBBasicTypeEnumeration (clang_type_t clang_type)

would return a bogus value.

llvm-svn: 165979

llvm-svn: 165862

I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:

virtual CommandObject *
GetPluginCommandObject();

This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented! 

llvm-svn: 165861

From SBType, we can now get a lldb::BasicType enumeration out of an existing type.

llvm-svn: 165857