Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183801 91177308-0d34-0410-b5e6-96231b3b80d8
COFF header is always present both in executable and in object file. PE header
is present only in executable. So the natural way to handle PE/COFF file is
treating COFF is mandatory header and PE is optional. Current data structre
does not allow it, because PE header includes COFF header. Removing COFF
header will simplify the code to handle PE/COFF files.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D952
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183788 91177308-0d34-0410-b5e6-96231b3b80d8
This enables the compiler to see the enum and produce warnings about a switch
not being fully covered. Fix one of these warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183749 91177308-0d34-0410-b5e6-96231b3b80d8
building outside projects with a different compiler than that used to build
LLVM itself (eg switching between gcc and clang).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183650 91177308-0d34-0410-b5e6-96231b3b80d8
Add a stringize method to make dumping a bit easier, and add a testcase
exercising a few different paths.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182692 91177308-0d34-0410-b5e6-96231b3b80d8
- Ressurect old MCDisassemble API to soften transition.
- Extend MCTargetDesc to set target specific symbolizer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182688 91177308-0d34-0410-b5e6-96231b3b80d8
There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.
Defines away PR16132.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182636 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182628 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
Solaris doesn't have an endian.h header, but SPARC is the only
big-endian architecture that runs Solaris, so just use that to detect
endianness at compile time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182419 91177308-0d34-0410-b5e6-96231b3b80d8
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181868 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181680 91177308-0d34-0410-b5e6-96231b3b80d8
- previously formatted_raw_ostream tracked columns, now it tracks lines too
- used by (upcoming) DebugIR pass to know the line number to connect to each IR
instruction
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181463 91177308-0d34-0410-b5e6-96231b3b80d8
All R_PPC_... relocs should also be present (using the same number)
under the corresponding R_PPC64_... name. The latter were missing
for a couple of cases, which this patch adds.
This is not a big problem when emitting the reloc, because we can
just use the R_PPC_... define instead. But it is a problem when
*dumping* relocations e.g. using llvm-readobj, because this will
expect only R_PPC64_... values when inspecting a ppc64 ELF file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181451 91177308-0d34-0410-b5e6-96231b3b80d8
A * (1 - (uitofp i1 C)) -> select C, 0, A
B * (uitofp i1 C) -> select C, B, 0
select C, 0, A + select C, B, 0 -> select C, B, A
These come up in code that has been hand-optimized from a select to a linear blend,
on platforms where that may have mattered. We want to undo such changes
with the following transform:
A*(1 - uitofp i1 C) + B*(uitofp i1 C) -> select C, A, B
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181216 91177308-0d34-0410-b5e6-96231b3b80d8
