llvm-svn: 164911

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
 int a = p->a;
 int b = p->b;
 q->a = a;
 q->b = b;

2. Consecutive stores where the values are constants. Foe example:
 q->a = 4;
 q->b = 5;

llvm-svn: 164910

llvm-svn: 164909

llvm-svn: 164908

llvm-svn: 164907

llvm-svn: 164906

llvm-svn: 164905

llvm-svn: 164904

llvm-svn: 164903

llvm-svn: 164902

llvm-svn: 164900

llvm-svn: 164899

llvm-svn: 164898

llvm-svn: 164897

broken as of r164656 as TemplateArgument::getAsDecl() now asserts
instead of returning NULL for other template arugment kinds.

llvm-svn: 164896

use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.

llvm-svn: 164892

alignment could lose it due to the alloca type moving down to a much
smaller alignment guarantee.

Now SROA will actively compute a proper alignment, factoring the target
data, any explicit alignment, and the offset within the struct. This
will in some cases lower the alignment requirements, but when we lower
them below those of the type, we drop the alignment entirely to give
freedom to the code generator to align it however is convenient.

Thanks to Duncan for the lovely test case that pinned this down. =]

llvm-svn: 164891

buildbots.  Original commit message:

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164890

llvm-svn: 164889

When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.  

<rdar://problem/7714201>

llvm-svn: 164888

Tidy up to match coding standards. Remove 'else' after 'return' and moving operators to end of preceding line. No functional change intended.

llvm-svn: 164887

Replace a couple if/elses around similar calls with conditional operators on the varying arguments. No functional change.

llvm-svn: 164886

A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work.  We only handle these cases:

1. Consecutive stores where the values and consecutive loads. For example:
  int a = p->a;
  int b = p->b;
  q->a = a;
  q->b = b;

2. Consecutive stores where the values are constants. Foe example:
  q->a = 4;
  q->b = 5;

llvm-svn: 164885

loaded at a random offset).

To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.

I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.

<rdar://problem/7714201>

llvm-svn: 164881

llvm-svn: 164880

llvm-svn: 164879

runtime, we read method signatures for both class
and instance methods out of the runtime data.

(lldb) fr var str
(NSString *) str = 0x0000000105000180 @"Hello from '/Volumes/Data/projects/lldb/test/lang/objc/foundation/a.out'"
(lldb) expr str.length
(unsigned long long) $0 = 72
(lldb) expr [NSString stringWithCString:"Hello world!" encoding:1]
(id) $1 = 0x0000000105100050
(lldb) po $1
$1 = 0x0000000105100050 Hello world!

(lldb) fr var array1
(NSArray *) array1 = 0x000000010010a6e0 @"3 objects"
(lldb) expr array1.count
(unsigned long long) $0 = 3
(lldb) expr [array1 objectAtIndex:2]
(id) $1 = 0x00000001000025d0
(lldb) po $1
$1 = 0x00000001000025d0 array1 object3

Notice that both regular and property-style notation
work.  I still need to add explicit support for
properties with non-default setters/getters.

This information is only queried if an Objective-C
object does not have debug information for a complete
type available.  Otherwise we query debug information
as usual.

llvm-svn: 164878

This reverts commit 6f61df3e7256413dcb99afb9673f4206e3c4992c.

llvm-svn: 164877

This reverts commit 0006ba445962621ed82ec84400a6b978205a3fbc.

llvm-svn: 164876

This reverts commit 580cd17f256259f39a382e967173f34d68e73859.

llvm-svn: 164875

an inclusion directive was automatically turned into a module import, and
PPCallbacks::moduleImport() for an explicit module import.

llvm-svn: 164874

llvm-svn: 164873

is the same as the suggested one when looking up the include filename.

llvm-svn: 164872

llvm-svn: 164871

<rdar://problem/12378910> Fixing a potential crasher in the data formatters where we fail to check for NULL or empty class name

llvm-svn: 164870

llvm-svn: 164869

the validation occurred.

The original implementation was pessimistic - we assumed that ivars
which escape are invalidated. This version is optimistic, it assumes
that the ivars will always be explicitly invalidated: either set to nil
or sent an invalidation message.

llvm-svn: 164868

llvm-svn: 164867

llvm-svn: 164866

This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface

There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.

Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command

For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands

Caveats:
	Currently, the new API objects and features are not exposed via Python.
	The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object)
	There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins
	There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own

llvm-svn: 164865