Also added a few comments.

llvm-svn: 249781

llvm-svn: 249780

Summary:
These non-semantic changes will help make a later change adding
support for deopt operand bundles more streamlined.

Reviewers: reames, swaroop.sridhar

Subscribers: sanjoy, llvm-commits

Differential Revision: http://reviews.llvm.org/D13491

llvm-svn: 249779

This is to enable me to address review for D13491 -- `Flags` is a
bitfield of `StatepointFlags`, not an individual item out of the enum,
so it should be represented as an `uint32_t`.

llvm-svn: 249778

Summary:
This will be used in a later change to RewriteStatepointsForGC.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D13490

llvm-svn: 249777

Summary: Use `const auto &` instead of `auto` in `makeStatepointExplicit`.

Reviewers: reames, swaroop.sridhar

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D13454

llvm-svn: 249776

These are enabled by default in clang-cl, because the whole idea is that
it should work like cl.exe, but I suppose it can make sense to disable
them if someone wants to compile code in a more strict mode.

llvm-svn: 249775

and expressions.  Also wired that into the OptionValue infrastructure, although
it isn't used for tab-completion yet.

llvm-svn: 249769

from malformed Mach-O files that caused a crash because of a
section header had a size that extended past the end of the file.

rdar://22983603

llvm-svn: 249768

Stop relying on ilist implicit conversions from `value_type&` to
`iterator` in YAMLParser.cpp.

I eventually want to outlaw this entirely.  It encourages
`getNextNode()` and `getPrevNode()` in iterator logic, which is
extremely fragile (and relies on them never returning `nullptr`).

FTR, there's nothing nefarious going on in this case, it was just easy
to clean up since the callers really wanted iterators to begin with.

llvm-svn: 249767

Clang supports SEH well enough that this should work out of the box.  If
it doesn't, we'll hear about it.

llvm-svn: 249766

llvm-svn: 249765

Stop using `getNextNode()` to get an insertion point (at least, in this
one place).  Instead, use iterator logic directly.

The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node.  It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.

llvm-svn: 249764

Stop using `getNextNode()` to get an iterator to a fragment (at least,
in this one place).  Instead, use iterator logic directly.

The `getNextNode()` interface isn't actually supposed to work for
creating iterators; it's supposed to return `nullptr` (not a real
iterator) if this is the last node.  It's currently broken and will
"happen" to work, but if we ever fix the function, we'll get some
strange failures in places like this.

llvm-svn: 249763

Even if we don't have it in PATH, lipo should usually exist in the same directory
as dsymutil. Keep the fallback looking up the PATH, it's very useful when
testing a non-installed executable.

llvm-svn: 249762

There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.

Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.

llvm-svn: 249761

The required page alignment is different on different targets. On PowerPC, for
example, we need 64K pages (the loader won't set different permissions on a
finer granularity than that). I've set the existing targets to what I believe
to be the correct values, and have updated the regression tests accordingly.

llvm-svn: 249760

CMake build rules listed -I flags for two different libc++ header
locations which broke when libc++ headers started using include_next.

Also change -I to -isystem to avoid compiler warning about
include_next.

llvm-svn: 249759

Stop using `getNextNode()` to create an insertion point for machine
instructions (at least, in this one place).  Instead, use an iterator.
As a drive-by, clean up dump statements to use iterator logic.

The `getNextNode()` interface isn't actually supposed to work for
insertion points; it's supposed to return `nullptr` if this is the last
node.  It's currently broken and will "happen" to work, but if we ever
fix the function, we'll get some strange failures.

llvm-svn: 249758

The size of a .plt entry is different on different targets (it is,
specifically, much larger than 8 on all PPC ABIs). There is no functional
change here (later patches to create .plt entries for PPC64 will depend on this
change).

llvm-svn: 249756

when they introduced android testsuite regressions.  Pavel has run the
testsuite against the updated patch and it completes cleanly now.

The original commit message:


Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely).

A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.

This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system.  It is not created by default
in normal dSYMs.

The problem was like this:

  1. lldb wants to find an executable, given only a UUID
     (this happens when lldb is doing cross-host debugging
      and doesn't have a copy of the target system's binaries)

  2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
     which does a spotlight search for the dSYM on the local
     system, and failing that, tries the DBGShellCommands
     command to find the dSYM.

  3. It gets a dSYM.  It reads the per-UUID plist in the dSYM.
     The dSYM has a DBGSymbolRichExecutable kv pair pointing to
     the binary on a network filesystem.

  4. Using the binary on the network filesystem, lldb now goes
     to find the dSYM.

  5. It starts by looking for a dSYM next to the binary it found.

  6. lldb is now reading the dSYM over a network filesystem,
     ignoring the one it found on its local filesystem earlier.

Everything still *works* but it's much slower.

This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.

One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find.  This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.

The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.

I ran the testsuites on mac, no new regressions introduced

<rdar://problem/21993813> 

llvm-svn: 249755

This is an implementation of
https://github.com/google/sanitizers/issues/579

It has a number of advantages over the current mapping:
* Works for non-PIE executables.
* Does not require ASLR; as a consequence, debugging MSan programs in
  gdb no longer requires "set disable-randomization off".
* Supports linux kernels >=4.1.2.
* The code is marginally faster and smaller.

This is an ABI break. We never really promised ABI stability, but
this patch includes a courtesy escape hatch: a compile-time macro
that reverts back to the old mapping layout.

llvm-svn: 249754

This is an implementation of
https://github.com/google/sanitizers/issues/579

It has a number of advantages over the current mapping:
* Works for non-PIE executables.
* Does not require ASLR; as a consequence, debugging MSan programs in
  gdb no longer requires "set disable-randomization off".
* Supports linux kernels >=4.1.2.
* The code is marginally faster and smaller.

This is an ABI break. We never really promised ABI stability, but
this patch includes a courtesy escape hatch: a compile-time macro
that reverts back to the old mapping layout.

llvm-svn: 249753

Reapply r249726 (and r249723), hopefully with the correct test fixups this time.

Original commit message:

Address a FIXME in ELF/Writer.cpp: Make VAStart a target-dependent property.
I've set the values for the existing targets to what I believe to be the
correct values, and updated the regression tests accordingly.

llvm-svn: 249752

llvm-svn: 249751

This is a simple refactoring that replaces Triple.getEnvironment()
checks for Android with Triple.isAndroid().

llvm-svn: 249750

llvm-svn: 249749

We were only doing this for SEH as a special case. Generalize it to all
cleanups.

llvm-svn: 249748

This involved changing the TypeSystem::CreateInstance to take a module or a target. This allows type systems to create an AST for modules (no expression support needed) or targets (expression support is needed) and return the correct class instance for both cases.

llvm-svn: 249747

Thanks to George Rimar's r249696, `not` is now able to find ld.lld2
executable correctly.

llvm-svn: 249746

While here fix a few more issues with potential overflow and add
new tests for these cases. Ensured that test now passes with UBSan.

llvm-svn: 249745

Found by inspection.

llvm-svn: 249744

llvm-svn: 249743

llvm-svn: 249742

llvm-svn: 249741

llvm-svn: 249740

llvm-svn: 249739

llvm-svn: 249738

Factor definition of std::nullptr_t out of <cstddef> into a header that can also be used by <stddef.h>.

llvm-svn: 249737

The only way for SecIndex to be zero in here is for an extended section
number to be zero, which would be an error.

llvm-svn: 249736