llvm-svn: 193844

llvm-svn: 193843

llvm-svn: 193842

llvm-svn: 193841

llvm-svn: 193840

Rename LIBUNWIND_AVAIL to LIBUNWIND_UNAVAIL so as to not conflict with other (different) LIBUNWIND_AVAIL define

llvm-svn: 193839

Patch by Peter Zotov

llvm-svn: 193838

do not remove the setter if its availability differs
from availability of the getter (which is now turned into
a property). Otherwise, synthesized setter will
inherit availability of the property (which is incorrect).
// rdar://15300059

llvm-svn: 193837

This commit only changes comments and documentation in OCaml bindings. The official name of the language is OCaml, and the usage is now consistent.

Patch by Peter Zotov

llvm-svn: 193836

Drive by space optimization. Also makes the DIEs more regular which
might speed up DWARF parsing.

llvm-svn: 193835

llvm-svn: 193834

Objective-C data structures.

This is allows tools such as darwin's otool(1) that uses the
LLVM disassembler take a pointer value being loaded by
an instruction and add a comment to what it is being referenced
to make following disassembly of Objective-C programs
more readable.

For example disassembling the Mac OS X TextEdit app one
will see comments like the following:

movq    0x20684(%rip), %rsi ## Objc selector ref: standardUserDefaults
movq    0x21985(%rip), %rdi ## Objc class ref: _OBJC_CLASS_$_NSUserDefaults
movq    0x1d156(%rip), %r14 ## Objc message: +[NSUserDefaults standardUserDefaults]
leaq    0x23615(%rip), %rdx ## Objc cfstring ref: @"SelectLinePanel"
callq   0x10001386c ## Objc message: -[[%rdi super] initWithWindowNibName:]

These diffs also include putting quotes around C strings
in literal pools and uses "symbol address" in the comment
when adding a symbol name to the comment to tell these
types of references apart:

leaq	0x4f(%rip), %rax ## literal pool for: "Hello world"
movq    0x1c3ea(%rip), %rax ## literal pool symbol address: ___stack_chk_guard

Of course the easy changes are in the LLVM disassembler and
the hard work is up to the implementer of the SymbolLookUp()
call back.

rdar://10602439

llvm-svn: 193833

In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.

Fixes bug #17551.

Patch by "/dev/humancontroller"

llvm-svn: 193832

llvm-svn: 193831

Given that, this test will never pass
Marking as expected failure pending a fix

llvm-svn: 193830

llvm-svn: 193829

Mark it as expected to fail pending a fix

llvm-svn: 193828

llvm-svn: 193827

llvm-svn: 193826

llvm-svn: 193825

llvm-svn: 193824

llvm-svn: 193823

llvm-svn: 193822

Workaround the DWARF info is anticipating the derived class assignment issue in this test case for now

llvm-svn: 193821

llvm-svn: 193820

llvm-svn: 193819

Further fixes to the dynamic type system prompted by ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command

llvm-svn: 193818

llvm-svn: 193817

llvm-svn: 193816

This change makes Module::buildVisibleModulesCache() collect exported modules
recursively.

While computing a set of exports, getExportedModules() iterates over the set of
imported modules and filters it.  But it does not consider the set of exports
of those modules -- it is the responsibility of the caller to do this.

Here is a certain instance of this issue.  Module::isModuleVisible says that
CoreFoundation.CFArray submodule is not visible from Cocoa.  Why?

- Cocoa imports Foundation.
- Foundation has an export restriction: "export *".
- Foundation imports CoreFoundation.  (Just the top-level module.)
- CoreFoundation exports CoreFoundation.CFArray.

To decide which modules are visible from Cocoa, we collect all exported modules
from immediate imports in Cocoa:

> visibleModulesFro(Cocoa) = exported(Foundation) + exported(CoreData) + exported(AppKit)

To find out which modules are exported, we filter imports according to
restrictions:

> exported(Foundation) = filterByModuleMapRestrictions(imports(Foundation))

Because Foundation imports CoreFoundation (not CoreFoundation.CFArray), the
CFArray submodule is considered not exported from Foundation, and is not
visible from Cocoa (according to Module::isModuleVisible).

llvm-svn: 193815

LWG issue 2341; Make the two variants of basic_ostream::seekp and basic_istream::seekg behave consistently; update tests to make sure

llvm-svn: 193814

llvm-svn: 193813

llvm-svn: 193812

Originally implemented by Lang Hames.

llvm-svn: 193811

llvm-svn: 193810

llvm-svn: 193809

Given that backend does not handle "invoke asm" correctly ("invoke asm" will be
handled by SelectionDAGBuilder::visitInlineAsm, which does not have the right
setup for LPadToCallSiteMap) and we already made the assumption that inline asm
does not throw in InstCombiner::visitCallSite, we are going to make the same
assumption in Inliner to make sure we don't convert "call asm" to "invoke asm".

If it becomes necessary to add support for "invoke asm" later on, we will need
to modify the backend as well as remove the assumptions that inline asm does
not throw.

Fix rdar://15317907

llvm-svn: 193808

Summary:
TSan and MSan need to know if interceptor was called by the
user code or by the symbolizer and use pre- and post-symbolization hooks
for that. Make Symbolizer class responsible for calling these hooks instead.
This would ensure the hooks are only called when necessary (during
in-process symbolization, they are not needed for out-of-process) and
save specific sanitizers from tracing all places in the code where symbolization
will be performed.

Reviewers: eugenis, dvyukov

Reviewed By: eugenis

CC: llvm-commits

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

llvm-svn: 193807

llvm-svn: 193806

llvm-svn: 193805