llvm-svn: 199742

No functional change

llvm-svn: 199741

Very sorry, I managed to completely forget "make check".

llvm-svn: 199739

No functional change

llvm-svn: 199738

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199737

llvm-svn: 199736

llvm-svn: 199735

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199734

There's nothing Darwin-based in the files or target now, so the previous name
is now misleading.

llvm-svn: 199733

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199732

    
Clang now uses the *-apple-macho triples for embedded targets using MachO. The
environment makes less pretences to be running an actual Mach kernel with all
the support that would imply, so a few changes are needed to the build scripts:
    
+ The Apple way of detecting endianness applies in all cases so drop the
  __MACH__ test.
+ A quick rename since "darwin_embedded" no longer makes any sense. If there's
  no Mach going on, there's certainly no Darwin.
+ Change how we test for support for a platform. The functions we build don't
  need any SDK support (stdio.h, ...) so we don't need to check for it.

llvm-svn: 199731

llvm-svn: 199730

Intercept and sanitize arguments passed to printf functions in ASan and TSan
(don't do this in MSan for now). The checks are controlled by runtime flag
(off by default for now).

Patch http://llvm-reviews.chandlerc.com/D2480 by Yuri Gribov!

llvm-svn: 199729

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199728

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199727

This code works with AAPCS-style {fp, lr} frames. Unlike linux perf, it does
not unwind through code compiled with -mapcs-frame (which Clang does not
support anyway).

llvm-svn: 199725

llvm-svn: 199724

llvm-svn: 199723

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199722

No functional change since the InstrItinData's have been duplicated.

llvm-svn: 199719

This is apparently a bit of a white lie (they can affect DSPControl for
overflow etc) but similar to how we currently handle floating-point operations.
When it becomes relevant the whole lot can be reviewed properly.

llvm-svn: 199718

llvm-svn: 199716

[asan] relax the checks inside __sanitizer_annotate_contiguous_container: they are too optimistic due to https://code.google.com/p/address-sanitizer/issues/detail?id=258.

llvm-svn: 199715

llvm-svn: 199714

Before:
  #if AAAA &&BBBB

After:
  #if AAAA && BBBB

llvm-svn: 199713

llvm-svn: 199712

Try to repair the ARM Cortex-A15 buildbot by using a more appropriate conversion
specifier.

llvm-svn: 199711

GCC warning about attributes on function definitions for both of them.

llvm-svn: 199710

llvm-svn: 199709

Add support to llvm-readobj to decode the actual opcodes.  The ARM EHABI opcodes
are a variable length instruction set that describe the operations required for
properly unwinding stack frames.

The primary motivation for this change is to ease the creation of tests for the
ARM EHABI object emission as well as the unwinding directive handling in the ARM
IAS.

Thanks to Logan Chien for an extra test case!

llvm-svn: 199708

This implements the unwind_raw directive for the ARM IAS.  The unwind_raw
directive takes the form of a stack offset value followed by one or more bytes
representing the opcodes to be emitted.  The opcode emitted will interpreted as
if it were assembled by the opcode assembler via the standard unwinding
directives.

Thanks to Logan Chien for an extra test!

llvm-svn: 199707

The .personalityindex directive is equivalent to the .personality directive with
the ARM EABI personality with the specific index (0, 1, 2).  Both of these
directives indicate personality routines, so enhance the personality directive
handling to take into account personalityindex.

Bonus fix: flush the UnwindContext at the beginning of a new function.

Thanks to Logan Chien for additional tests!

llvm-svn: 199706

llvm-svn: 199705

It was commited as r199628 but reverted in r199628 as causing
regression test failed. It's because of old vervsion of patch
I used to commit. Sorry for mistake.

llvm-svn: 199704

llvm-svn: 199703

the header forwards to operator== which is not in the header.

llvm-svn: 199702

we can see exactly what data was put where.

llvm-svn: 199701

I misunderstood the discussion on this. The complexity here is
justified by the malloc overhead it saves.

This reverts commit r199302.

llvm-svn: 199700

llvm-svn: 199699

to not guess at a symbol name in some cases.

The problem is that in object files assembled starting at address 0, when
trying to symbolicate something that starts like this:

% cat x.s
_t1:
	vpshufd	$0x0, %xmm1, %xmm0

the symbolic disassembly can end up like this:

% otool -tV x.o 
x.o:
(__TEXT,__text) section
_t1:
0000000000000000	vpshufd	$_t1, %xmm1, %xmm0

Which is in this case produced incorrect symbolication.

But it is useful in some cases to use the SymbolLookUp() call back
to guess at some immediate values.  For example one like this
that does not have an external relocation entry:

% cat y.s
_t1:
	movl	$_d1, %eax
.data
_d1:	.long	0

% clang -c -arch i386 y.s

% otool -tV y.o 
y.o:
(__TEXT,__text) section
_t1:
0000000000000000	movl	$_d1, %eax

% otool -rv y.o 
y.o:
Relocation information (__TEXT,__text) 1 entries
address  pcrel length extern type    scattered symbolnum/value
00000001 False long   False  VANILLA False     2 (__DATA,__data)

So the change is based on it is not likely that an immediate Value
coming from an instruction field of a width of 1 byte, other than branches
and items with relocation, are not likely symbol addresses.

With the change the first case above simply becomes:

% otool -tV x.o 
x.o:
(__TEXT,__text) section
_t1:
0000000000000000	vpshufd	$0x0, %xmm1, %xmm0

and the second case continues to work as expected.

rdar://14863405

llvm-svn: 199698