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

when used with symbolic disassembly, add a check that the operand
is an immediate and has not been symbolicated to MCExpr operand.

I’m trying to enable the ‘C’ disassembly API option
LLVMDisassembler_Option_SetInstrComments for darwin’s
otool(1) that uses the llvm disassembler API.  The problem is
that the disassembler API can change an immediate operand to
an MCExpr operand if it symbolicates it with the call backs.
And if it does the code in llvm::EmitAnyX86InstComments()
will crash when it assumes these operands are immediates.

The fix for this is very straight forward to just protect the call
to getImm() with a check of isImm().  So if the immediate for
an instruction is symbolicated it simply doesn’t get the X86
verbose assembly comments:

% otool -tV test_asm.o
test_asm.o:
(__TEXT,__text) section
_t1:
0000000000000000	vpshufd	$_t1, %xmm1, %xmm0
0000000000000005	retq
0000000000000006	nopw	%cs:_t1(%rax,%rax)
_t2:
0000000000000010	vpshufd	$-0x1, %xmm0, %xmm0     ## xmm0 = xmm0[3,3,3,3]
0000000000000015	retq
0000000000000016	nopw	%cs:_t1(%rax,%rax)
_t3:
0000000000000020	vpshufd	$_t1, %xmm1, %xmm0
0000000000000025	retq
0000000000000026	nopw	%cs:_t1(%rax,%rax)
_t4:
0000000000000030	vpshufd	$0x2d, %xmm0, %xmm0     ## xmm0 = xmm0[1,3,2,0]
0000000000000035	retq

The fact that the immediate $0x0 is being symbolicated at
all in this case is a different problem which my next patch
will address.

rdar://10989286

llvm-svn: 199697

Recent versions of the iOS simulator no longer require linking with the
crt1.o, dylib1.o, or bundle1.o files. The relevant code is now included in
libSystem for the simulator.

llvm-svn: 199696