llvm-svn: 146511

llvm-svn: 146508

llvm-svn: 146507

llvm-svn: 146505

in classes. // rdar://10535349

llvm-svn: 146504

llvm-svn: 146503

load and then move the result from a GPR to a FPR.

llvm-svn: 146502

llvm-svn: 146501

build compiler-rt with -fPIC, otherwise the run-time libs will not link with -pie, at least on linux

llvm-svn: 146499

rdar://10573361

llvm-svn: 146498

rdar://10567864&10567916

llvm-svn: 146497

@class forward references.

rdar://10568080&10568103&10568119

llvm-svn: 146496

llvm-svn: 146493

instructions that define aggregate types.

llvm-svn: 146492

llvm-svn: 146487

llvm-svn: 146486

llvm-svn: 146485

llvm-svn: 146484

Tweak ARC diagnostic categories and rename 'Automatic Reference Counting Issue' to 'ARC Parse Issue' and 'ARC Issue' to 'ARC Semantic Issue'.  Patch by Jean-Daniel Dupas.

llvm-svn: 146483

Added an assertion about overflow in sizeof evaluation. This does not solve the underlying structural issue that is waiting for a proper solution.

llvm-svn: 146482

Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown
during -O0 compilation. We don't necessarily need to generate an aggregate of
the values here if they're just going to be extracted directly afterwards.
<rdar://problem/10530851>

llvm-svn: 146481

llvm-svn: 146480

be constant expressions.

llvm-svn: 146479

Check that the pc value for frames up the stack is in a
mapped+executable region of memory.

Check that the stack pointer for frames up the stack is
in a mapped+readable region of memory.

If the unwinder ever makes a mistake walking the stack,
these checks will help to keep it from going too far into
the weeds.

These aren't fixing any bugs that I know of, but they
add extra robustness to a complicated task.

llvm-svn: 146478

if this is a mapped/executable region of memory.  If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.  

Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64 
ArchDefaultUnwindPlan which relied on the rbp.

Fixes <rdar://problem/10508291>

llvm-svn: 146477

llvm-svn: 146476

DW_FORM_flag. Use DW_FORM_data1 for one byte.

llvm-svn: 146475

I'm not sure I have this right but it looks correct.

llvm-svn: 146474

parse.

llvm-svn: 146473

llvm-svn: 146472

having the block, then timing out & letting all threads run actually works.

llvm-svn: 146471

elf-relsym.ll.

llvm-svn: 146470

in a 16-bit field.

llvm-svn: 146469

test cases where there were a lot of relocations applied relative to a large
rodata section. Gas would create a symbol for each of these whereas we would
be relative to the beginning of the rodata section. This change mimics what
gas does.

Patch by Jack Carter.

llvm-svn: 146468

of the targets we know about. Because this is cached, rebuilds won't
detect when new targets show up. It's also a bit simpler to just say
"all". If users want to restrict the target set, they can still do so,
and then the cache will preserve what they have explicitly set this
field to.

llvm-svn: 146467

undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.

Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.

Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.

llvm-svn: 146466

validates the "self," "this," and "_cmd" pointers
that get passed into expressions.  It used to check
them aggressively for validity before allowing the
expression to run as an object method; now, this
functionality is gated by a bool and off by default.

Now the default is that when LLDB is stopped in a
method of a class, code entered using "expr" will
always masquerade as an instance method.  If for
some reason "self," "this," or "_cmd" is unavailable
it will be reported as NULL.  This may cause the
expression to crash if it relies on those pointers,
but for example getting the addresses of ivars will
now work as the user would expect.

llvm-svn: 146465

llvm-svn: 146463

Modified the Xcode project to not strip liblldb-core.a for BuildAndIntegration builds
and to correctly strip only debug symbols from the command line binaries.

llvm-svn: 146462

llvm-svn: 146461