getRelocationAddress is for dynamic libraries and executables,
getRelocationOffset for relocatable objects.

Mark the getRelocationAddress of COFF and MachO as not implemented yet. Add a
test of ELF's. llvm-readobj -r now prints the same values as readelf -r.

llvm-svn: 180259

Instead, we check for one line extern "C" context in linkage computation and
when deciding if a variable is a definition.

This hopefully completes the transition to having "as written" semantics for
hasExternalStorage.

llvm-svn: 180258

llvm-svn: 180255

Fix constant folding for one lane vector types. Constant folding one lane vector types not returns a vector instead of a scalar.

llvm-svn: 180254

This enables formattings like:

  #define A   \
    int aaaa; \
    int b;    \
    int ccc;  \
    int dddddddddd;

Enabling this for Google/Chromium styles only as I don't know whether it
is desired for Clang/LLVM.

llvm-svn: 180253

This patch ensure that nothing scrolls even if the same buffer is opened
in multiple windows.

llvm-svn: 180252

llvm-svn: 180251

This includes the following fixes:
 - Implement 4 subtly different variants of qualifier mangling and use them
   in what I believe are the right places.
 - Fix handling of array types.  Previously we were always decaying them,
   which is wrong if the type appears as a template argument, pointee,
   referent etc.
Fixes PR13182.

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

llvm-svn: 180250

This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a.

Looks like it broke the valgrind bot:

http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649

llvm-svn: 180249

This reverts commit 8c31b298149ca3c3f2bbd9e8aa9a01c4d91f3d74.

It looks like this commit broke some bots:

http://lab.llvm.org:8011/builders/llvm-ppc64-linux2/builds/5209

llvm-svn: 180248

llvm-svn: 180247

llvm-svn: 180246

llvm-svn: 180245

In Process::ProcessEventData::DoOnRemoval, we need to handle the case where NO thread has a stop reason
specially, and make sure we stop.  This shouldn't happen, but if it does, the user will probably want to
see it.

<rdar://problem/13273125>

llvm-svn: 180244

llvm-svn: 180243

llvm-svn: 180242

Patch by Zoran Jovanovic.

llvm-svn: 180241

Summary:
No change if the identity isn't defined by the makefile.

Reviewers: echristo

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

llvm-svn: 180240

llvm-svn: 180239

Patch by Zoran Jovanovic.

llvm-svn: 180238

If a register is in a ValueObject, be sure to print its children if it is a vector type.

llvm-svn: 180237

Don't print the type if there is none and don't print "<invalid type>". ValueObjects can be register sets and register groups and dumping those with:

(lldb) script print frame.GetRegisters()

llvm-svn: 180236

Don't crash if we try to interpret the IR (incorrectly in this case) and can't handle the size. This came from trying to do:

(lldb) p typedef float __attribute__((ext_vector_type(8))) __ext_vector_float8; (__ext_vector_float8)$ymm0

llvm-svn: 180235

[analyzer] Fix a crash in RetainCountChecker - we should not rely on CallEnter::getCallExpr to return non-NULL

We get a CallEnter with a null expression, when processing a destructor. All other users of
CallEnter::getCallExpr work fine with null as return value.

(Addresses PR15832, Thanks to Jordan for reducing the test case!)

llvm-svn: 180234

[neonemitter tests] Change triple of emitted tests to thumbv7s to match the target cpu being swift. Also specify the target-abi to apcs-gnu.

llvm-svn: 180233

llvm-svn: 180232

Fixes test/CodeGen/R600/setcc.ll

llvm-svn: 180231

The libelf implementation that is distributed here:
http://www.mr511.de/software/english.html
will not parse sections that are marked SHT_NULL.

llvm-svn: 180230

Patch by Filip Pizlo

llvm-svn: 180229

when class implementation declaration adds protocol qualifier
list. // rdar://12233858

llvm-svn: 180228

Fixes PR15838. Need to check for blocks with nothing but dbg.value.

I'm not sure how to force this situation with a unit test. I tried to
reduce the test case in PR15838 (1k lines of metadata) but gave up.

llvm-svn: 180227

rdar://13731657

llvm-svn: 180226

llvm-svn: 180225

Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)).

There is a new static ObjectFile function you can call:

size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
                                     lldb::offset_t file_offset,
                                     ModuleSpecList &specs)

This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).

This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.

llvm-svn: 180224

llvm-svn: 180223

[objc-arc] Added ImpreciseAutoreleaseSet to track autorelease calls that were once autoreleaseRV instructions.

Due to the semantics of ARC, we must be extremely conservative with autorelease
calls inserted by the frontend since ARC gaurantees that said object will be in
the autorelease pool after that point, an optimization invariant that the
optimizer must respect.

On the other hand, we are allowed significantly more flexibility with
autoreleaseRV instructions.

Often times though this flexibility is disrupted by early transformations which
transform objc_autoreleaseRV => objc_autorelease if said instruction is no
longer being used as part of an RV pair (generally due to inlining). Since we
can not tell the difference in between an autorelease put into place by the
frontend and one created through said ``strength reduction'' we can not perform
these optimizations.

The addition of this set gets around said issues by allowing us to differentiate
in between said two cases.

rdar://problem/13697741.

llvm-svn: 180222

llvm-svn: 180221

Contributer: Vladimir Medic
llvm-svn: 180220

See: http://stackoverflow.com/questions/16166897/c-how-to-obtain-address-of-stdvector-object-in-lldb-xcode
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too

llvm-svn: 180219

“plugin load” tries to be more helpful when it fails to load a plugin

llvm-svn: 180218