Simplify the handling of iterators in ObjectFile.

None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or

Simplify the handling of iterators in ObjectFile.

None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().

This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.

llvm-svn: 200442

show more ...

Fix "llvm-objdump -d -r" to show relocations inline for ELF files

This fixes a regression introduced by r182908, which broke
llvm-objdump's ability to display relocations inline in a disassembly
dum

Fix "llvm-objdump -d -r" to show relocations inline for ELF files

This fixes a regression introduced by r182908, which broke
llvm-objdump's ability to display relocations inline in a disassembly
dump for ELF object files.

That change removed a SectionRelocMap from Object/ELF.h, which we
recreate in llvm-objdump.cpp.

I discovered this regression via an out-of-tree test
(test/NaCl/X86/pnacl-hides-sandbox-x86-64.ll) which used llvm-objdump.

Note that the "Unknown" string in the test output on i386 isn't quite
right, but this appears to be a pre-existing bug.

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

llvm-svn: 200090

show more ...

llvm-objdump: Some style cleanups to follow LLVM coding style

Rename "ec" to "EC", and rename some iterators.

Then fix whitespace using clang-format-diff.

(As requested in http://llvm-reviews.chan

llvm-objdump: Some style cleanups to follow LLVM coding style

Rename "ec" to "EC", and rename some iterators.

Then fix whitespace using clang-format-diff.

(As requested in http://llvm-reviews.chandlerc.com/D2559)

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

llvm-svn: 200053

show more ...

Rename these methods to match the style guide.

llvm-svn: 199751

Return an ErrorOr<Binary *> from createBinary.

I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too
cumbersome to use without std::move. I will keep the patch locally and submi

Return an ErrorOr<Binary *> from createBinary.

I did write a version returning ErrorOr<OwningPtr<Binary> >, but it is too
cumbersome to use without std::move. I will keep the patch locally and submit
when we switch to c++11.

llvm-svn: 199326

show more ...

Re-submit r191472 with a fix for big endian.

llvm-objdump: Dump COFF import table if -private-headers option is given.
llvm-svn: 191557

Revert "llvm-objdump: Dump COFF import table if -private-headers option is given."

This reverts commit r191472 because it's failing on BE machine.

llvm-svn: 191480

llvm-objdump: Dump COFF import table if -private-headers option is given.

This is a patch to add capability to llvm-objdump to dump COFF Import Table
entries, so that we can write tests for LLD chec

llvm-objdump: Dump COFF import table if -private-headers option is given.

This is a patch to add capability to llvm-objdump to dump COFF Import Table
entries, so that we can write tests for LLD checking Import Table contents.

llvm-objdump did not print anything but just file name if the format is COFF
and -private-headers option is given. This is a patch adds capability for
dumping DLL Import Table, which is specific to the COFF format.

In this patch I defined a new iterator to iterate over import table entries.
Also added a few functions to COFFObjectFile.cpp to access fields of the entry.

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

llvm-svn: 191472

show more ...

Add basic YAML MC CFG testcase.

Drive-by llvm-objdump cleanup (don't hardcode ToolName).

llvm-svn: 188904

MC CFG: Add YAML MCModule representation to enable MC CFG testing.

Like yaml ObjectFiles, this will be very useful for testing the MC CFG
implementation (mostly MCObjectDisassembler), by matching th

MC CFG: Add YAML MCModule representation to enable MC CFG testing.

Like yaml ObjectFiles, this will be very useful for testing the MC CFG
implementation (mostly MCObjectDisassembler), by matching the output
with YAML, and for potential users of the MC CFG, by using it as an input.

There isn't much to the actual format, it is just a serialization of the
MCModule class. Of note:
- Basic block references (pred/succ, ..) are represented by the BB's
start address.
- Just as in the MC CFG, instructions are MCInsts with a size.
- Operands have a prefix representing the type (only register and
immediate supported here).
- Instruction opcodes are represented by their names; enum values aren't
stable, enum names mostly are: usually, a change to a name would need
lots of changes in the backend anyway.
Same with registers.

All in all, an example is better than 1000 words, here goes:

A simple binary:

Disassembly of section __TEXT,__text:
_main:
100000f9c: 48 8b 46 08 movq 8(%rsi), %rax
100000fa0: 0f be 00 movsbl (%rax), %eax
100000fa3: 3b 04 25 48 00 00 00 cmpl 72, %eax
100000faa: 0f 8c 07 00 00 00 jl 7 <.Lend>
100000fb0: 2b 04 25 48 00 00 00 subl 72, %eax
.Lend:
100000fb7: c3 ret

And the (pretty verbose) generated YAML:

---
Atoms:
- StartAddress: 0x0000000100000F9C
Size: 20
Type: Text
Content:
- Inst: MOV64rm
Size: 4
Ops: [ RRAX, RRSI, I1, R, I8, R ]
- Inst: MOVSX32rm8
Size: 3
Ops: [ REAX, RRAX, I1, R, I0, R ]
- Inst: CMP32rm
Size: 7
Ops: [ REAX, R, I1, R, I72, R ]
- Inst: JL_4
Size: 6
Ops: [ I7 ]
- StartAddress: 0x0000000100000FB0
Size: 7
Type: Text
Content:
- Inst: SUB32rm
Size: 7
Ops: [ REAX, REAX, R, I1, R, I72, R ]
- StartAddress: 0x0000000100000FB7
Size: 1
Type: Text
Content:
- Inst: RET
Size: 1
Ops: [ ]
Functions:
- Name: __text
BasicBlocks:
- Address: 0x0000000100000F9C
Preds: [ ]
Succs: [ 0x0000000100000FB7, 0x0000000100000FB0 ]
<snip>
...

llvm-svn: 188890

show more ...

Use pointers to the MCAsmInfo and MCRegInfo.

Someone may want to do something crazy, like replace these objects if they
change or something.

No functionality change intended.

llvm-svn: 184175

llvm-objdump.cpp: Appease MSC16 x64. utostr(n++) causes internal compiler error.

llvm-svn: 182722

MC: Disassembled CFG reconstruction.

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.
- MCAto

MC: Disassembled CFG reconstruction.

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

show more ...

Add MCSymbolizer for symbolic/annotated disassembly.

This is a basic first step towards symbolization of disassembled
instructions. This used to be done using externally provided (C API)
callbacks.

Add MCSymbolizer for symbolic/annotated disassembly.

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

show more ...

llvm-objdump: Initialize MCDisassembler once instead of for each section.

llvm-svn: 182054

Remove the MachineMove class.

It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarf

Remove the MachineMove class.

It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarfRegNum are pushed out, which
should allow further simplifications.

I left the MachineModuleInfo::addFrameMove interface unchanged since
this patch was already fairly big.

llvm-svn: 181680

show more ...

Clarify getRelocationAddress x getRelocationOffset a bit.

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

Mark the getRelocationAddress o

Clarify getRelocationAddress x getRelocationOffset a bit.

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

show more ...

At Jim Grosbach's request detemplate Object/MachO.h.

We are still able to handle mixed endian objects by swapping one struct at a
time.

llvm-svn: 179778

llvm-objdump: Don't print contents of BSS sections: it makes no sense and crashes llvm-objdump on relocated objects with large bss

llvm-svn: 179589

Finish templating MachObjectFile over endianness.

We are now able to handle big endian macho files in llvm-readobject. Thanks to
David Fang for providing the object files.

llvm-svn: 179440

Convert MachOObjectFile to a template.

For now it is templated only on being 64 or 32 bits. I will add little/big
endian next.

llvm-svn: 179097

Don't fetch pointers from a InMemoryStruct.

InMemoryStruct is extremely dangerous as it returns data from an internal
buffer when the endiannes doesn't match. This should fix the tests on big
endian

Don't fetch pointers from a InMemoryStruct.

InMemoryStruct is extremely dangerous as it returns data from an internal
buffer when the endiannes doesn't match. This should fix the tests on big
endian hosts.

llvm-svn: 178875

show more ...

Don't disassemble symbols with an unknown address or size.

Patch by Nico Rieck!

llvm-svn: 178678

Add static cast to unsigned char whenever a character classification function is called with a signed char argument, in order to avoid assertions in Windows Debug configuration.

llvm-svn: 175006

[objdump,readobj] Document the purpose and goals of each tool.

llvm-svn: 174439