llvm-svn: 183947

llvm-svn: 183941

llvm-svn: 183940

llvm-svn: 183928

llvm-svn: 183912

llvm-svn: 183909

llvm-svn: 183908

It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.

llvm-svn: 183864

These records are mandatory for executables and are used by the loader.

Reviewers: rafael

CC: llvm-commits

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

llvm-svn: 183852

llvm-svn: 183840

This is preparation for replacing Path.h with PathV2.h.

llvm-svn: 183782

No functionality change.

llvm-svn: 183759

Should bring bots back to life.

llvm-svn: 183715

Currently, only emitting the ELF header is supported (no sections or
segments).

The ELFYAML code organization is broadly similar to the COFFYAML code.

llvm-svn: 183711

llvm-svn: 183669

llvm-svn: 183526

from the LC_DATA_IN_CODE load command.  And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.

I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.

rdar://11791371

llvm-svn: 183424

llvm-svn: 183403

This avoids making assumptions about the data representation.

llvm-svn: 183349

Previously, yaml2coff.cpp had a writeHexData static helper function to
do this, but it is generally useful functionality.

Also, validate hex strings up-front to avoid running having to handle
errors "deep inside" the yaml2obj code (it also gives better diagnostics
than it used to).

llvm-svn: 183345

llvm-svn: 183335

See the comment in yaml2obj.cpp for why this is currently needed.
Eventually we can get rid of this, but for now it is needed in order to
make forward progress with adding ELF support, and should be
straightforward to remove later.

Also, preserve the default of COFF, to avoid breaking existing tests.
This policy can easily be changed later though.

llvm-svn: 183332

It will be used for ELF dumping too.

llvm-svn: 183287

In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.

llvm-svn: 183284

Specifying the load address for Darwin i386 dylibs was a performance
optimization for dyld that is not relevant for x86_64 or arm. We can just
remove this now.

llvm-svn: 183230

[llvm-symbolizer] Avoid calling slow getSymbolSize for Mach-O files. Assume that symbols with zero size are in fact large enough.

llvm-svn: 183213

Thanks to Sean Silva for noticing it!

llvm-svn: 183148

llvm-svn: 183102

llvm-svn: 183042

llvm-svn: 183040

Not only does this break encapsulation, it's gross.

llvm-svn: 182876

llvm-svn: 182722

llvm-svn: 182680

This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
  contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
  backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
  disassembler. It first builds an atom for each section. It can also
  construct the CFG, and this splits the text atoms into basic blocks.

MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.

In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).

This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.

Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.

llvm-svn: 182628

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

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

llvm-svn: 182611

I will try to avoid creating these std::strings, but for now this gets
the tests passing with libc++.

llvm-svn: 182405

On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.

llvm-svn: 182209

llvm-svn: 182172

llvm-svn: 182169