ARM bots (& others, I think, now that I look) were failing because we
were using incorrect printf-style format specifiers. They were wrong
on almost any platform, actually, just mostly harmlessly so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215196 91177308-0d34-0410-b5e6-96231b3b80d8
Also make the disassembler created with the Mach-O parser (the -m option)
pick up the Target specific attributes specified with -mattr option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215032 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get
a reference to it.
Thanks to David Blaikie for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214516 91177308-0d34-0410-b5e6-96231b3b80d8
The size of the uninitialized sections, like BSS, can exceed the size of
the object file.
Do not attempt to grab the contents of such sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212953 91177308-0d34-0410-b5e6-96231b3b80d8
The new library is 150KB on a Release+Asserts build, so it is quiet a bit of
code that regular users of MC don't need to link with now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212209 91177308-0d34-0410-b5e6-96231b3b80d8
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211749 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211546 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are
easy to use.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211033 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.
The cases where the general idea needed some tweaking:
* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.
* Template specialization had to be moved to the std namespace in this
patch set already.
* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.
Despite these shortcomings I think this is still a good thing. Some reasons:
* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210687 91177308-0d34-0410-b5e6-96231b3b80d8
Immutable DILineInfo doesn't bring any benefits and complicates
code. Also, use std::string instead of SmallString<16> for file
and function names - their length can vary significantly.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206654 91177308-0d34-0410-b5e6-96231b3b80d8
Since LLVM currently only supports WinCOFF, assume that the input is WinCOFF
rather than another type of COFF file (ECOFF/XCOFF). If the architecture is
detected as thumb (e.g. the file has a IMAGE_FILE_MACHINE_ARMNT magic) then use
a triple of thumbv7-windows.
This allows for objdump to properly handle WoA object files without having to
specify the target triple manually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206446 91177308-0d34-0410-b5e6-96231b3b80d8
This patch re-introduces the MCContext member that was removed from
MCDisassembler in r206063, and requires that an MCContext be passed in at
MCDisassembler construction time. (Previously the MCContext member had been
initialized in an ad-hoc fashion after construction). The MCCContext member
can be used by MCDisassembler sub-classes to construct constant or
target-specific MCExprs.
This patch updates disassemblers for in-tree targets, and provides the
MCRegisterInfo instance that some disassemblers were using through the
MCContext (previously those backends were constructing their own
MCRegisterInfo instances).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206241 91177308-0d34-0410-b5e6-96231b3b80d8
Once the auxiliary fields relating to the filename have been inspected, any
following auxiliary fields need not be visited as they have been consumed (the
following fields comprise the filepath as a single unit).
Adjust the test to catch this even if ASAN is not enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206190 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than switching behaviour on whether a previous symbol has an auxiliary
symbol record for the next count of elements, simply iterate over the auxiliary
symbols right after processing the current symbol entry. This makes the
behaviour much simpler to follow and similar to llvm-readobj and yaml2obj.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206146 91177308-0d34-0410-b5e6-96231b3b80d8
If a filename is a multiple of 18 characters, there will be no null-terminator.
This will result in an invalid access by the constructed StringRef. Add a test
case to exercise this and fix that handling. Address this same vulnerability in
llvm-readobj as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206145 91177308-0d34-0410-b5e6-96231b3b80d8
The auxiliary file records are contiguous and only contain the filename.
Construct a StringRef directly rather than copying to a temporary buffer.
Suggested by majnemer on IRC!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206139 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for file auxiliary symbol entries in COFF symbol tables. A COFF
symbol table with a FILE entry is followed by sizeof(__FILE__) / 18 auxiliary
symbol records which contain the filename. Read them and form the original
filename that the record contains. Then display the name in the output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206126 91177308-0d34-0410-b5e6-96231b3b80d8
The current state of affairs has auxiliary symbols described as a big
bag of bytes. This is less than satisfying, it detracts from the YAML
file as being human readable.
Instead, allow for symbols to optionally contain their auxiliary data.
This allows us to have a much higher level way of describing things like
weak symbols, function definitions and section definitions.
This depends on D3105.
Differential Revision: http://llvm-reviews.chandlerc.com/D3092
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204214 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preliminary setup change to support a renaming of Windows target
triples. Split the object file format information out of the environment into a
separate entity. Unfortunately, file format was previously treated as an
environment with an unknown OS. This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203160 91177308-0d34-0410-b5e6-96231b3b80d8
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203083 91177308-0d34-0410-b5e6-96231b3b80d8
Unwind info contents were indented at the same level as function table
contents. That's a bit confusing because the unwind info is pointed by
function table. In other places we usually increment indentation depth
by one when dereferncing a pointer.
This patch also removes extraneous newlines between function tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202879 91177308-0d34-0410-b5e6-96231b3b80d8
The original code does not work correctly on executable files because the
code is written in such a way that only object files are assumed to be given
to llvm-objdump.
Contents of RuntimeFunction are different between executables and objects. In
executables, fields in RuntimeFunction have actual addresses to unwind info
structures. On the other hand, in object files, the fields have zero value,
but instead there are relocations pointing to the fields, so that Linker will
fill them at link-time.
So, when we are reading an object file, we need to use relocation info to
find the location of unwind info. When executable, we should just look at the
values in RuntimeFunction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202785 91177308-0d34-0410-b5e6-96231b3b80d8
The current COFF unwind printer tries to print SEH handler function names,
assuming that it can always find function names in string table. It crashes
if file being read has no symbol table (i.e. executable).
With this patch, llvm-objdump prints SEH handler's RVA if there's no symbol
table entry for that RVA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202466 91177308-0d34-0410-b5e6-96231b3b80d8
boundaries.
It is possible to create an ELF executable where symbol from say .text
section 'points' to the address outside the section boundaries. It does
not have a sense to disassemble something outside the section.
Without this fix llvm-objdump prints finite or infinite (depends on
the executable file architecture) number of 'invalid instruction
encoding' warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202083 91177308-0d34-0410-b5e6-96231b3b80d8
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
SEH table addresses are VA in COFF file. In this patch we convert VA to RVA
before printing it, because dumpbin prints them as RVAs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201760 91177308-0d34-0410-b5e6-96231b3b80d8
Load Configuration Table may contain a pointer to SEH table. This patch is to
print the offset to the table. Printing SEH table contents is a TODO.
The layout of Layout Configuration Table is described in Microsoft PE/COFF
Object File Format Spec, but the table's offset/size descriptions seems to be
totally wrong, at least in revision 8.3 of the spec. I believe the table in
this patch is the correct one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201638 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200090 91177308-0d34-0410-b5e6-96231b3b80d8
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200018 91177308-0d34-0410-b5e6-96231b3b80d8
The constructors of classes deriving from Binary normally take an error_code
as an argument to the constructor. My original intent was to change them
to have a trivial constructor and move the initial parsing logic to a static
method returning an ErrorOr. I changed my mind because:
* A constructor with an error_code out parameter is extremely convenient from
the implementation side. We can incrementally construct the object and give
up when we find an error.
* It is very efficient when constructing on the stack or when there is no
error. The only inefficient case is where heap allocating and an error is
found (we have to free the memory).
The result is that this is a much smaller patch. It just standardizes the
create* helpers to return an ErrorOr.
Almost no functionality change: The only difference is that this found that
we were trying to read past the end of COFF import library but ignoring the
error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199770 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the capability to dump export table contents. An example
output is this:
Export Table:
Ordinal RVA Name
5 0x2008 exportfn1
6 0x2010 exportfn2
By adding this feature to llvm-objdump, we will be able to use it to check
export table contents in LLD's tests. Currently we are doing binary
comparison in the tests, which is fragile and not readable to humans.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199358 91177308-0d34-0410-b5e6-96231b3b80d8
If a binary does not depend on any DLL, it does not contain import table at
all. Printing the section title without contents looks wrong, so we shouldn't
print it in that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199340 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199326 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191472 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189321 91177308-0d34-0410-b5e6-96231b3b80d8
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>
...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188890 91177308-0d34-0410-b5e6-96231b3b80d8
* ELFTypes.h contains template magic for defining types based on endianess, size, and alignment.
* ELFFile.h defines the ELFFile class which provides low level ELF specific access.
* ELFObjectFile.h contains ELFObjectFile which uses ELFFile to implement the ObjectFile interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188022 91177308-0d34-0410-b5e6-96231b3b80d8
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184175 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183284 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
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180259 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to Evgeniy Stepanov for reporting this.
It might be a good idea to add a command iterator abstraction to MachO.h, but
this fixes the bug for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179848 91177308-0d34-0410-b5e6-96231b3b80d8
We are now able to handle big endian macho files in llvm-readobject. Thanks to
David Fang for providing the object files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179440 91177308-0d34-0410-b5e6-96231b3b80d8
LoadCommandInfo was needed to keep a command and its offset in the file. Now
that we always have a pointer to the command, we don't need the offset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178991 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178875 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies the usage and implementation of ELFObjectFile by using ELFType
to replace:
<endianness target_endianness, std::size_t max_alignment, bool is64Bits>
This does complicate the base ELF types as they must now use template template
parameters to partially specialize for the 32 and 64bit cases. However these
are only defined once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172515 91177308-0d34-0410-b5e6-96231b3b80d8
On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one
anonymous, segment.
This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be inform
the linker with segment this section should go to.
The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.
The main difference from the previous patch is that it doesn't use
InMemoryStruct. It is extremely dangerous: if the endians match it returns
a pointer to the file buffer, if not, it returns a pointer to an internal buffer
that is overwritten in the next API call.
We should change all of this code to use
support::detail::packed_endian_specific_integral like ELF, but since these
functions only handle strings, they work with big and little endian machines
as is.
I have tested this by installing ubuntu 12.10 ppc on qemu, that is why it took
so long :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170838 91177308-0d34-0410-b5e6-96231b3b80d8
I cannot reproduce it the failures locally, so I will keep an eye at the ppc
bots. This patch does add the change to the "Disassembly of section" message,
but that is not what was failing on the bots.
Original message:
Add a funciton to get the segment name of a section.
On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one
anonymous, segment.
This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be infor
the linker with segment this section should go to.
The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170545 91177308-0d34-0410-b5e6-96231b3b80d8
On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one,
anonymous, segment.
This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be informing
the linker with segment this section should go to.
The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170095 91177308-0d34-0410-b5e6-96231b3b80d8
The new command line option -unwind-info dumps the Win64 EH unwind
data to the console. This is a nice feature if you need to debug
generated EH data (e.g. from LLVM). Includes a test case.
Initial patch by João Matos, extensions and rework by Kai Nacke.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169415 91177308-0d34-0410-b5e6-96231b3b80d8
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169252 91177308-0d34-0410-b5e6-96231b3b80d8
delimited. llvm-mc -disassemble access these through the -mattr
option.
llvm-objdump -disassemble had no such way to set the attribute so
some instructions were just not recognized for disassembly.
This patch accepts llvm-mc mechanism for specifying the attributes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162781 91177308-0d34-0410-b5e6-96231b3b80d8
Rename ST_External to ST_Unknown, and slightly change its semantics. It now only indicates that the symbol's type
is unknown, not that the symbol is undefined. (For that, use ST_Undefined).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151696 91177308-0d34-0410-b5e6-96231b3b80d8
This CL delays reading of function bodies from initial parse until
materialization, allowing overlap of compilation with bitcode download.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149918 91177308-0d34-0410-b5e6-96231b3b80d8
dylib. This regressed with r145408. I will try to make a test case and add it
so that this doesn't happen again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149667 91177308-0d34-0410-b5e6-96231b3b80d8
flags as binutils objdump but the output is different, not just in format but
also showing different sections. Compare its results against readelf, not
objdump.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141579 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r141377 into '.':
U tools/llvm-objdump/MachODump.cpp
--- Reverse-merging r141376 into '.':
U include/llvm/Object/COFF.h
U include/llvm/Object/ObjectFile.h
U include/llvm-c/Object.h
U tools/llvm-objdump/llvm-objdump.cpp
U lib/Object/MachOObjectFile.cpp
U lib/Object/COFFObjectFile.cpp
U lib/Object/Object.cpp
U lib/Object/ELFObjectFile.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141379 91177308-0d34-0410-b5e6-96231b3b80d8
- It can take FunctionStarts from a binary to find entry points more accurately.
- Symbol offsets in executables are correct now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140028 91177308-0d34-0410-b5e6-96231b3b80d8
- Add enum SymbolType and function getSymbolType()
- Add function isGlobal() - it's returns true for symbols that can be used in another objects, such as library functions.
- Rename function getAddress() to getOffset() and add new function getAddress(), because currently getAddress() returns section offset of symbol first byte. new getAddress() return symbol address.
- Change usage SymbolRef::getAddress() to getOffset() in tools/llvm-nm and tools/llvm-objdump.
Patch by Danil Malyshev!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139683 91177308-0d34-0410-b5e6-96231b3b80d8
In "normal" code these only happen when disassembling data, so we
won't lose anything if we just drop them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135786 91177308-0d34-0410-b5e6-96231b3b80d8
the Support library. Now its part of the TargetRegistry, and the three
commands that care about this explicitly register this extra bit of
version information.
The set of commands which care was computed by intersecting those which
use the Support library's version string printing and those that
initialize all the registered targets in a way that produces
a meaningful list. The only odd ball out is that 'clang -cc1as -version'
no longer prints the registered targets. I don't think anyone is really
interested in that (especially as the fact that llvm-mc does so is under
a FIXME), but if someone really does want this back I'll happily apply
the same patch there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135757 91177308-0d34-0410-b5e6-96231b3b80d8
- Not great yet, but it's a start.
- Requires an object file with a symbol table. (I really want to fix this, but it'll need a whole new algorithm)
- ELF and COFF won't work at the moment due to libObject shortcomings.
To try it out run
$ llvm-objdump -d --cfg foo.o
This will create a graphviz file for every symbol in the object file's text section containing a CFG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135608 91177308-0d34-0410-b5e6-96231b3b80d8
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135468 91177308-0d34-0410-b5e6-96231b3b80d8
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134127 91177308-0d34-0410-b5e6-96231b3b80d8
the alias of an InstAlias instead of the thing being aliased. Because we need to
know the features that are valid for an InstAlias.
This is part of a work-in-progress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127986 91177308-0d34-0410-b5e6-96231b3b80d8
