Enhance lldb so it can search for a kernel in memory when attaching
to a remote system.  Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.

I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to

 none   - for environments where reading random memory can cause a
          device crash 
 basic  - look at one fixed location in memory for a kernel load address, 
          plus the contents of that address
 fast-scan - the default, tries "basic" and then looks for the kernel's
          mach header near the current pc value when lldb connects
 exhaustive-scan - on 32-bit targets, step through the entire range where
          the kernel can be loaded, looking for the kernel binary

I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels 
appear to be working correctly with these changes.

llvm-svn: 173891

This adds a new --with-python option to allow configuration of the python binary
for building.  If not specified, $PATH will be searched for common python binary
names (python, python2, python3).  If specified, and the path is not executable,
it will attempt to search $PATH.

Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Eric Christopher &lt;echristo@gmail.com&gt;, Daniel Dunbar <daniel@zuster.org>
llvm-svn: 173890

Summary:
A motivating example:
class ClassWithDtor {
public:
  ~ClassWithDtor() {}
};
void fallthrough3(int n) {
  switch (n) {
    case 2:
      do {
        ClassWithDtor temp;
        return;
      } while (0);  // This generates a chain of unreachable CFG blocks.
    case 3:
      break;
  }
}

Reviewers: rsmith, doug.gregor, alexfh

Reviewed By: alexfh

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D330

llvm-svn: 173889

llvm-svn: 173888

llvm-svn: 173887

llvm-svn: 173886

setting of ELF header e_flags.

Contributer: Jack Carter
 
llvm-svn: 173885

setting of ELF header e_flags.

Contributer: Jack Carter
 
llvm-svn: 173884

unresolved using declarations. Fixes PR14768 / <rdar://problem/13030296>.

llvm-svn: 173883

and update ELF header e_flags.

Currently gathering information such as symbol, 
section and data is done by collecting it in an 
MCAssembler object. From MCAssembler and MCAsmLayout 
objects ELFObjectWriter::WriteObject() forms and 
streams out the ELF object file.

This patch just adds a few members to the MCAssember 
class to store and access the e_flag settings. It 
allows for runtime additions to the e_flag by 
assembler directives. The standalone assembler can 
get to MCAssembler from getParser().getStreamer().getAssembler().

This patch is the generic infrastructure and will be
followed by patches for ARM and Mips for their target 
specific use.

Contributer: Jack Carter
 
llvm-svn: 173882

People use the C preprocessor for things other than C files. Some of them
have Unicode characters. We shouldn't warn about Unicode characters
appearing outside of identifiers in this case.

There's not currently a way for the preprocessor to tell if it's in -E mode,
so I added a new flag, derived from the PreprocessorOutputOptions. This is
only used by the Unicode warnings for now, but could conceivably be used by
other warnings or even behavioral differences later.

<rdar://problem/13107323>

llvm-svn: 173881

Suggested in post-commit review by Richard Smith.

llvm-svn: 173880

http://llvm-reviews.chandlerc.com/D332



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173879

This simply fixes up quoting of macro invocations to appease newer versions of autotools.

http://llvm-reviews.chandlerc.com/D332



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173878

Additional quoting for safety and satisfying newer autotools.  Fix a couple of 80 column violations.

http://llvm-reviews.chandlerc.com/D333



Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
llvm-svn: 173877

This is needed to allow constant time access to the final layout of atoms.

llvm-svn: 173874

If the member has an initializer, assume it was probably intended to be static
and suggest/recover with that.

If the member doesn't have an initializer, assume it was probably intended to
be const instead of constexpr and suggest that.

(if the attempt to apply these changes fails, don't make any suggestion &
produce the same diagnostic experience as before. The only case where this can
come up that I know of is with a mutable constexpr with an initializer, since
mutable is incompatible with static (but it's already incompatible with
const anyway))

llvm-svn: 173873

argument to be memset, check for its type to be complete 
before calling Context.getTypeSize(PointeeTy) to prevent 
crash. // rdar://13081751.

llvm-svn: 173872

llvm-svn: 173871

- remove nullptr from initialization of shared_ptrs

llvm-svn: 173870

llvm-svn: 173867

llvm-svn: 173866

llvm-svn: 173865

llvm-svn: 173864

Patch by Sasa Stankovic.

llvm-svn: 173863

Patch by Sasa Stankovic.

llvm-svn: 173862

If we had the regular expression "\b" in FileCheck like Perl...

llvm-svn: 173861

llvm-svn: 173860

 - The only group where it makes sense for the "ExternC" bit is System, so this
   simplifies having to have the extra isCXXAware (or ImplicitExternC, depending
   on what code you talk to) bit caried around.

llvm-svn: 173859

Cleaned up the objective C name parsing code to use a class.

Now breakpoints that are set by name that are objective C methods without the leading '+' or '-' will resolve. We do this by expanding all the objective C names for a given string. For example:

(lldb) b [MyString cStringUsingEncoding:]

Will set a breakpoint with multiple possible names: 
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]

Also if you have a category, it will strip the category and set a breakpoint in all variants:

(lldb) [MyString(my_category) cStringUsingEncoding:]

Will resolve to the following names:

-[MyString(my_category) cStringUsingEncoding:]
+[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]
+[MyString cStringUsingEncoding:]

Likewise when we have:

(lldb) b -[MyString(my_category) cStringUsingEncoding:]

It will resolve to two names:
-[MyString(my_category) cStringUsingEncoding:]
-[MyString cStringUsingEncoding:]

llvm-svn: 173858

llvm-svn: 173857

my last patch.

llvm-svn: 173856

 - This slightly decouples the path handling, since before the group sometimes
   dominated the "use sysroot" bit, but it was still passed in via the API.

 - No functionality change.

llvm-svn: 173855

llvm-svn: 173854

llvm-svn: 173853

minor cleanup.

llvm-svn: 173852

references to their UTIF-8 encoding. Reviewed offline by Doug.
// rdar://12392215

llvm-svn: 173850

Changing ARMBaseTargetMachine to return ARMTargetLowering intead of
the generic one (similar to x86 code).

Tests showing which instructions were added to cast when necessary
or cost zero when not. Downcast to 16 bits are not lowered in NEON,
so costs are not there yet.

llvm-svn: 173849

implementation; this is much more inline with the original implementation
(i.e., pre-ubsan) and does not require run-time library support.

The trapping implementation can be invoked using either '-fcatch-undefined-behavior'
or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter
being preferred.  Eventually, the -fcatch-undefined-behavior' flag will be removed.

llvm-svn: 173848

llvm-svn: 173847