This is a basic first step towards symbolization of disassembled
instructions. This used to be done using externally provided (C API)
callbacks. This patch introduces:
- the MCSymbolizer class, that mimics the same functions that were used
  in the X86 and ARM disassemblers to symbolize immediate operands and
  to annotate loads based off PC (for things like c string literals).
- the MCExternalSymbolizer class, which implements the old C API.
- the MCRelocationInfo class, which provides a way for targets to
  translate relocations (either object::RelocationRef, or disassembler
  C API VariantKinds) to MCExprs.
- the MCObjectSymbolizer class, which does symbolization using what it
  finds in an object::ObjectFile. This makes simple symbolization (with
  no fancy relocation stuff) work for all object formats!
- x86-64 Mach-O and ELF MCRelocationInfos.
- A basic ARM Mach-O MCRelocationInfo, that provides just enough to
  support the C API VariantKinds.

Most of what works in otool (the only user of the old symbolization API
that I know of) for x86-64 symbolic disassembly (-tvV) works, namely:
- symbol references: call _foo; jmp 15 <_foo+50>
- relocations:       call _foo-_bar; call _foo-4
- __cf?string:       leaq 193(%rip), %rax ## literal pool for "hello"
Stub support is the main missing part (because libObject doesn't know,
among other things, about mach-o indirect symbols).

As for the MCSymbolizer API, instead of relying on the disassemblers
to call the tryAdding* methods, maybe this could be done automagically
using InstrInfo? For instance, even though PC-relative LEAs are used
to get the address of string literals in a typical Mach-O file, a MOV
would be used in an ELF file. And right now, the explicit symbolization
only recognizes PC-relative LEAs. InstrInfo should have already have
most of what is needed to know what to symbolize, so this can
definitely be improved.

I'd also like to remove object::RelocationRef::getValueString (it seems
only used by relocation printing in objdump), as simply printing the
created MCExpr is definitely enough (and cleaner than string concats).

llvm-svn: 182625

building the resulting expression because it invokes a deleted constructor.

llvm-svn: 182624

llvm-svn: 182620

llvm-svn: 182619

[PowerPC] Remove symbolLo/symbolHi instruction operand types

Now that there is no longer any distinction between symbolLo
and symbolHi operands in either printing, encoding, or parsing,
the operand types can be removed in favor of simply using
s16imm.

This completes the patch series to decouple lo/hi operand part
processing from the particular instruction whose operand it is.

No change in code generation expected from this patch.

llvm-svn: 182618

- move AsmWriter.h from public headers into lib
- marked all AssemblyWriter functions as non-virtual; no need to override them
- DebugIR now "plugs into" AssemblyWriter with an AssemblyAnnotationWriter helper
- exposed flags to control hiding of a) debug metadata b) debug intrinsic calls

C/R: Paul Redmond

llvm-svn: 182617

[PowerPC] Clean up generation of ha16() / lo16() markers

When targeting the Darwin assembler, we need to generate markers ha16() and
lo16() to designate the high and low parts of a (symbolic) immediate.  This
is necessary not just for plain symbols, but also for certain symbolic
expression, typically along the lines of ha16(A - B).  The latter doesn't
work when simply using VariantKind flags on the symbol reference.
This is why the current back-end uses hacks (explicitly called out as such
via multiple FIXMEs) in the symbolLo/symbolHi print methods.

This patch uses target-defined MCExpr codes to represent the Darwin
ha16/lo16 constructs, following along the lines of the equivalent solution
used by the ARM back end to handle their :upper16: / :lower16: markers.
This allows us to get rid of special handling both in the symbolLo/symbolHi
print method and in the common code MCExpr::print routine.  Instead, the
ha16 / lo16 markers are printed simply in a custom print routine for the
target MCExpr types.  (As a result, the symbolLo/symbolHi print methods
can now replaced by a single printS16ImmOperand routine that also handles
symbolic operands.)

The patch also provides a EvaluateAsRelocatableImpl routine to handle
ha16/lo16 constructs.  This is not actually used at the moment by any
in-tree code, but is provided as it makes merging into David Fang's
out-of-tree Mach-O object writer simpler.

Since there is no longer any need to treat VK_PPC_GAS_HA16 and
VK_PPC_DARWIN_HA16 differently, they are merged into a single
VK_PPC_ADDR16_HA (and likewise for the _LO16 types).

llvm-svn: 182616

llvm-svn: 182615

Before: f(new vector<int> { 1, 2, 3 });
After:  f(new vector<int>{ 1, 2, 3 });
llvm-svn: 182614

1. Added new :Lpo command
2. :Lpo and :Lprint can be invoked without parameters. In that case
cursor word will be used
3. Added :LpO command in that case instead of <cword> will be used
stripped <cWORD>. This command is useful for printing objective-c
properties (for ex.: self.tableView). 

Patch by Arthur Evstifeev!!

llvm-svn: 182613

This essentially combines the tests in plist-output.m and plist-alternate-output.m.

llvm-svn: 182612

Move the processing of the command line options to right before we create the
TargetMachine instead of after.
<rdar://problem/13468287>

llvm-svn: 182611

Which means "platform process list" should work and list the architecture.
We are now parsing the elf build-id if it exists, which should allow us to load stripped symbols (looking at that next).

llvm-svn: 182610

settings set use-color [false|true]
settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} "
also "--no-use-colors" on the command prompt

llvm-svn: 182609

Previously we started sequences to align for single line comments when
the previous line had a trailing comment, but the sequence was broken
for other reasons.

Now we re-format:
// a
 // b
f(); // c
to:
// a
// b
f(); // c

llvm-svn: 182608

Make sure to not call "regexec" from <regex.h> with a NULL C string, otherwise we can crash.

llvm-svn: 182607

llvm-svn: 182606

Now correctly leaves:
f(); // comment
// comment
g(); // comment
... alone if the middle comment was aligned with g() before formatting.

llvm-svn: 182605

The ARM cycle-counter can be restricted by the operating system; it's
worth warning potential users of this issue.

llvm-svn: 182604

This implements the @llvm.readcyclecounter intrinsic as the specific
MRC instruction specified in the ARM manuals for CPUs with the Power
Management extensions.

Older CPUs had slightly different methods which may also have to be
implemented eventually, but this should cover all v7 cases.

rdar://problem/13939186

llvm-svn: 182603

Performance monitors, including a basic cycle counter, are an official
extension in the ARMv7 specification. This adds support for enabling and
disabling them, orthogonally from CPU selection.

rdar://problem/13939186

llvm-svn: 182602

Also fix a minor bug for constructor initializers with braced init lists.

llvm-svn: 182601

Patch by: Vincent Lejeune

https://bugs.freedesktop.org/show_bug.cgi?id=64877

NOTE: This is a candidate for the 3.3 branch.
llvm-svn: 182600

llvm-svn: 182599

llvm-svn: 182598

Before: vector<int> v{ -1};
After:  vector<int> v{-1};
llvm-svn: 182597

Put this somewhere on your path and use:

git clang-format

Awesome work by Mark Lodato. Many thanks!

llvm-svn: 182596

Reviewers: shankarke

CC: llvm-commits

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

llvm-svn: 182595

llvm-svn: 182594

Now that the LiveDebugVariables pass is running *after* register
coalescing, the ConnectedVNInfoEqClasses class needs to deal with
DBG_VALUE instructions.

This only comes up when rematerialization during coalescing causes the
remaining live range of a virtual register to separate into two
connected components.

llvm-svn: 182592

llvm-svn: 182590

llvm-svn: 182589

llvm-svn: 182588

Also removes an unused function.

llvm-svn: 182587

Lets us use a SetVector instead of an explicit set + vector combination.

llvm-svn: 182586

Setting the default value (fixes CRT assertions about uninitialized variable use when doing debug MSVC builds), and fixing coding style.

llvm-svn: 182585

The error was:
error: non-constant-expression cannot be narrowed from type 'long long' to 'long' in initializer list [-Wc++11-narrowing]
        MI.getOperand(6).getImm() & 0x1F,

llvm-svn: 182584

"check-lsan" now runs both the tests from lib/lsan/tests and any lit
tests found under lib/lsan/lit_tests.

llvm-svn: 182583

llvm-svn: 182582

llvm-svn: 182580