llvm-svn: 175497

twice.

llvm-svn: 175496

to search for kexts on the local system -- the ModuleList FindModule()
method is the best first attempt, only call
Symbols::DownloadObjectAndSymbolFile() if that has failed and this
is the kernel binary which really needs to have its symbols located.

<rdar://problem/13241893> 

llvm-svn: 175495

find a binary on the debugger-host during a kernel debug session
for a kernel extension (kext).  This may prove to be too verbose
in typical usage, particularly if there are many third-party kexts.
We'll try this and see how it works.

<rdar://problem/13080833> 

llvm-svn: 175494

llvm-svn: 175493

llvm-svn: 175492

a kernel binary - even if we can't find the symbol-rich binary or 
dSYM on the debugger-system.  Print a warning if the symbol-rich binary
cannot be located.  This more closely emulates the gdb behavior when
a kernel debug session failed to locate a kernel binary.

<rdar://problem/13016095> 

llvm-svn: 175491

llvm-svn: 175490

of kernel extensions (kexts) that have been loaded into the kernel.
Now when we hit the "kexts have changed" breakpoint we can avoid
adding kexts multiple times, and can properly detect kext unloads
and remove them from the Target's list of modules.

<rdar://problem/13107639>
<rdar://problem/13191016>

llvm-svn: 175489

llvm-svn: 175488

llvm-svn: 175487

BtnezT8SltiX16, BtnezT8SltiuX16 .

llvm-svn: 175486

llvm-svn: 175485

llvm-svn: 175484

Fixing a typo where FixIts was accidentally self-assigning instead of assigning in the parameter Fixits. This fixes several failed assertions with MSVC debug builds.

llvm-svn: 175483

fields were only ever set in the constructor. The create method retains
its consistent interface so that these bits can be re-threaded through
the emitter if they're ever needed.

This was found by the -Wunused-private-field Clang warning.

llvm-svn: 175482

const U *>>. Even in C++11 it doesn't seem this is valid as vector's
emplace support requires move assignment, and there is no way to move
assign a reference.

The real motivation however is that this fixes the build of lld with
libstdc++ 4.6.

llvm-svn: 175481

We treat this as an alternative to -fvisibility=<?>
which changes the default value visibility to "hidden"
and the default type visibility to "default".

Expose a -cc1 option for changing the default type
visibility, repurposing -fvisibility as the default
value visibility option (also setting type visibility
from it in the absence of a specific option).

rdar://13079314

llvm-svn: 175480

not the global visibility mode.

Noticed by inspection.

llvm-svn: 175479

llvm-svn: 175478

llvm-svn: 175477

llvm-svn: 175476

llvm-svn: 175475

llvm-svn: 175474

llvm-svn: 175472

llvm-svn: 175471

llvm-svn: 175470

llvm-svn: 175469

Synthetic children provider for NSSet

llvm-svn: 175468

llvm-svn: 175467

Also removes some redundant DNI comments on function declarations already
using the macro.

llvm-svn: 175466

Also removes some redundant DNI comments on function declarations already
using the macro.

llvm-svn: 175465

llvm-svn: 175464

llvm-svn: 175463

The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).

Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.

llvm-svn: 175462

llvm-svn: 175460

If the memcpy has an odd length with an alignment of 2, this would incorrectly
assert on the last 1 byte copy.
rdar://13202135

llvm-svn: 175459

llvm-svn: 175458

llvm-svn: 175457

llvm-svn: 175456