This has the following advantages:
* Less code.
* The old ELF implementation was wrong for non-relocatable objects.
* The old ELF implementation (and I think MachO) was wrong for thumb.
No current testcase since this is only used from MCJIT and it only uses
relocatable objects and I don't think it supports thumb yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205508 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r205479.
It turns out that nm does use addresses, it is just that every reasonable
relocatable ELF object has sections with address 0. I have no idea if those
exist in reality, but it at least it shows that llvm-nm should use the name
address.
The added test was includes an unusual .o file with non 0 section addresses. I
created it by hacking ELFObjectWriter.cpp.
Really sorry for the churn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205493 91177308-0d34-0410-b5e6-96231b3b80d8
What llvm-nm prints depends on the file format. On ELF for example, if the
file is relocatable, it prints offsets. If it is not, it prints addresses.
Since it doesn't really need to care what it is that it is printing, use the
generic term value.
Fix or implement getSymbolValue to keep llvm-nm working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205479 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The FileHeader mapping now accepts an optional Flags sequence that accepts
the EF_<arch>_<flag> constants. When not given, Flags defaults to zero.
Reviewers: atanasyan
Reviewed By: atanasyan
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3213
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205173 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
Some targets require more than one relocation entry to perform a relocation.
This change allows processRelocationRef to process more than one relocation
entry at a time by passing the relocation iterator itself instead of just
the relocation entry.
Related to <rdar://problem/16199095>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204439 91177308-0d34-0410-b5e6-96231b3b80d8
NumberOfRelocations field in COFF section table is only 16-bit wide. If an
object has more than 65535 relocations, the number of relocations is stored
to VirtualAddress field in the first relocation field, and a special flag
(IMAGE_SCN_LNK_NRELOC_OVFL) is set to Characteristics field.
In test we cheated a bit. I made up a test file so that it has
IMAGE_SCN_LNK_NRELOC_OVFL flag but the number of relocations is much smaller
than 65535. This is to avoid checking in a large test file just to test a
file with many relocations.
Differential Revision: http://llvm-reviews.chandlerc.com/D3139
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204418 91177308-0d34-0410-b5e6-96231b3b80d8
We would emit a pair of double quotes inside a pair of single quotes.
Just use a pair of single quotes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204312 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
Allow object files to be tagged with a version-min load command for iOS
or MacOSX.
Teach macho-dump to understand the version-min load commands for
testcases.
rdar://11337778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204190 91177308-0d34-0410-b5e6-96231b3b80d8
Since our error_category is based on the std one, we should have the
same visibility for the constructor. This also allows us to avoid
using the _do_message implementation detail in our own categories.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203998 91177308-0d34-0410-b5e6-96231b3b80d8
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds ObjectFile::section_iterator_range, that allows to write
range-based for-loops running over all sections of a given file.
Several files from lib/ are converted to the new interface. Similar fixes
should be applied to a variety of llvm-* tools.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3069
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203799 91177308-0d34-0410-b5e6-96231b3b80d8
Add the Windows COFF ARM object file magic. This enables the LLVM tools to
interact with COFF object files for Windows on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203761 91177308-0d34-0410-b5e6-96231b3b80d8
The official specifications state the name to be ARMNT (as per the Microsoft
Portable Executable and Common Object Format Specification v8.3).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203530 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
This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202959 91177308-0d34-0410-b5e6-96231b3b80d8
COFF object files with 0 as string table size are currently rejected. This
prevents us from reading object files written by tools like cvtres that
violate the PECOFF spec and write 0 instead of 4 for the size of an empty
string table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202292 91177308-0d34-0410-b5e6-96231b3b80d8
Offsets past the range of single-slash encoding are encoded as base64,
padded to 6 characters, and prefixed with two slashes. This encoding is
undocumented but used by MSVC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201940 91177308-0d34-0410-b5e6-96231b3b80d8
This interface allows IRObjectFile to be implemented without having dummy
methods for all section and segment related methods.
Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is
still not plugged in since it requires some refactoring to make a Module hold
a DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201881 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
It is not clear how much we should try to expose in getFlags. For example,
should there be a SF_Object and a SF_Text?
But for information that is already being exposed, we may as well use it in
llvm-nm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200820 91177308-0d34-0410-b5e6-96231b3b80d8
COFF has only one symbol table.
MachO has a LC_DYSYMTAB, but that is not a symbol table, just extra info about
the one symbol table (LC_SYMTAB).
IR (coming soon) also has only one table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200488 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 will be better with c++11, but right now file_magic converts to bool,
which makes the api really easy to misuse.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200357 91177308-0d34-0410-b5e6-96231b3b80d8
PE32+ supports 64 bit address space, but the file format remains 32 bit.
So its file format is pretty similar to PE32 (32 bit executable). The
differences compared to PE32 are (1) the lack of "BaseOfData" field and
(2) some of its data members are 64 bit.
In this patch, I added a new member function to get a PE32+ Header object to
COFFObjectFile class and made llvm-readobj to use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200117 91177308-0d34-0410-b5e6-96231b3b80d8
identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199813 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
DataRefImpl (a union of two integers and a pointer) is not the ideal data type
to represent a reference to an import directory entity. We should just use the
pointer to the import table and an offset instead to simplify. No functionality
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199349 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
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
0xffff does not mean that there are 65535 sections in a COFF file but
indicates that it's a COFF import library. This patch fixes SEGV error
when an import library file is passed to llvm-readobj.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194844 91177308-0d34-0410-b5e6-96231b3b80d8
There is still a long way to go for llvm-nm, but at least we now match
nm's letter output in the cases we test for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193912 91177308-0d34-0410-b5e6-96231b3b80d8
Some background: One can pass compiled resource files (.res files) directly
to the linker on Windows. If a resource file is given, the linker will run
"cvtres" command in background to convert the resource file to a COFF file
to link it.
What I'm trying to do with this patch is to make the linker to recognize
the resource file by file magic, so that it can run cvtres command.
Differential Revision: http://llvm-reviews.chandlerc.com/D1943
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192742 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
Right now we have two headers for the Mach-O format. I'd like to get rid
of one. Since the other object formats are all in Support, I chose to
keep the Mach-O header in Support, and discard the other one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189314 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
this records relocation entries in the mach-o object file
for PIC code generation.
tested on powerpc-darwin8, validated against darwin otool -rvV
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188004 91177308-0d34-0410-b5e6-96231b3b80d8
for StringRef with a StringMap
The bug is that the empty key compares equal to the tombstone key.
Also added an assertion to DenseMap to catch similar bugs in future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187866 91177308-0d34-0410-b5e6-96231b3b80d8
If no other operation is specified, 's' becomes an operation instead of an
modifier. The s operation just creates a symbol table. It is the same as
running ranlib.
We assume the archive was created by a sane ar (like llvm-ar or gnu ar) and
if the symbol table is present, then it is current. We use that to optimize
the most common case: a broken build system that thinks it has to run ranlib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187353 91177308-0d34-0410-b5e6-96231b3b80d8
The Binary constructor takes ownership of the memory buffer. This is a fairly
unfortunate interface, but for now make createObjectFile consistent with it
by also deleting the buffer if it fails.
Fixes a leak in llvm-ar found by the valgrind bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187039 91177308-0d34-0410-b5e6-96231b3b80d8
The original change was rolled back in r186627 because of test
failures on the big endian machine. I believe I fixed the issue
so re-submitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186734 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Dump optional data directory entries in the PE/COFF header, so that
we can test the output of LLD linker. This patch updates the test binary
file, but the source of the binary is the same. I just re-linked the file.
I don't know how the previous file was linked, but the previous file did
not have any data directory entries for some reason.
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1148
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186623 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes two bugs is lib/Object that the use in llvm-ar found:
* In OS X created archives, the name can be padded with nulls. Strip them.
* In the constructor, remember the first non special member and use that in
begin_children. This makes sure we skip all special members, not just the
first one.
The change to llvm-ar itself consist of
* Using lib/Object for reading archives instead of ArchiveReader.cpp.
* Writing the modified archive directly, instead of creating an in memory
representation.
The old Archive library was way more general than what is needed, as can
be seen by the diffstat of this patch.
Having llvm-ar using lib/Object now opens the way for creating regular symbol
tables for both native objects and bitcode files so that we can use those
archives for LTO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186197 91177308-0d34-0410-b5e6-96231b3b80d8
It is always computed the same way (by parsing the header). Doing it in the
constructor simplifies the callers a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185905 91177308-0d34-0410-b5e6-96231b3b80d8
This a bit more efficient and avoids having a function that uses the string
table being called by a function that searches for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185680 91177308-0d34-0410-b5e6-96231b3b80d8
Although in reality the symbol table in ELF resides in a section, the
standard requires that there be no more than one SHT_SYMTAB. To enforce
this constraint, it is cleaner to group all the symbols under a
top-level `Symbols` key on the object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184627 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, just have 3 sub-lists, one for each of
{STB_LOCAL,STB_GLOBAL,STB_WEAK}.
This allows us to be a lot more explicit w.r.t. the symbol ordering in
the object file, because if we allowed explicitly setting the STB_*
`Binding` key for the symbol, then we might have ended up having to
shuffle STB_LOCAL symbols to the front of the list, which is likely to
cause confusion and potential for error.
Also, this new approach is simpler ;)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184506 91177308-0d34-0410-b5e6-96231b3b80d8
After this patch, the ELF file produced by
`yaml2obj-elf-symbol-basic.yaml`, when linked and executed on x86_64
(under SysV ABI, obviously; I tested on Linux), produces a working
executable that goes into an infinite loop!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184469 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the compiler to see the enum and warn about it. While in here,
fix a switch to not use a default and fix style violations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184186 91177308-0d34-0410-b5e6-96231b3b80d8
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184019 91177308-0d34-0410-b5e6-96231b3b80d8
For consistency, change the address in the test case from 0xDEADBEEF to
0xCAFEBABE since 0xCAFEBABE that actually has a 2-byte alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183962 91177308-0d34-0410-b5e6-96231b3b80d8
The current functionality is extremely basic and a bit rough around the
edges, but it will flesh out in future commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183953 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
Currently, only emitting the ELF header is supported (no sections or
segments).
The ELFYAML code organization is broadly similar to the COFFYAML code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183711 91177308-0d34-0410-b5e6-96231b3b80d8
sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183605 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
This hides the implementation. A future commit will remove the
error-prone getHex() and getBinary() methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183352 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183345 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
For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.
In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.
In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.
This patch exposes that in the ObjectFile API. It has the following advantages:
* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.
* llvm-readobj now prints relocations in the same way the native readelf does.
* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182908 91177308-0d34-0410-b5e6-96231b3b80d8
There were two problems that made llvm-objdump -r crash:
- for non-scattered relocations, the symbol/section index is actually in the
(aptly named) symbolnum field.
- sections are 1-indexed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181843 91177308-0d34-0410-b5e6-96231b3b80d8
It was only implemented for ELF where it collected the Addend, so this
patch also renames it to getRelocationAddend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181502 91177308-0d34-0410-b5e6-96231b3b80d8
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.
This new file just contains the macros for defining different wrap/unwrap
methods.
The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.
Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.
This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8
For regular object files this is only meaningful for common symbols. An object
file format with direct support for atoms should be able to provide alignment
information for all symbols.
This replaces getCommonSymbolAlignment and fixes
test-common-symbols-alignment.ll on darwin. This also includes a fix to
MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common
(already tested by existing mcjit tests now that it is used).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180736 91177308-0d34-0410-b5e6-96231b3b80d8
For Mach-O there were 2 implementations for parsing object files. A
standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which
implements the generic interface in llvm/Object/ObjectFile.h.
This patch adds the missing features to MachO.h, moves macho-dump to
use MachO.h and removes ObjectFile.h.
In addition to making sure that check-all is clean, I checked that the
new version produces exactly the same output in all Mach-O files in a
llvm+clang build directory (including executables and shared
libraries).
To test the performance, I ran macho-dump over all the files in a
llvm+clang build directory again, but this time redirecting the output
to /dev/null. Both the old and new versions take about 4.6 seconds
(2.5 user) to finish.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
Since the relocation iterator walks only the relocations in one section, we
can just use a pointer and avoid fetching information about the section at
every reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180262 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
While here, don't report a dummy symbol for relocations that don't have symbols.
We used to says such relocations were for the first defined symbol, but now we
return end_symbols(). The llvm-readobj output change agrees with otool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180214 91177308-0d34-0410-b5e6-96231b3b80d8
This should bring the ppc bots back. I will try to write a test that would
have found the problem on a little endian system too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180194 91177308-0d34-0410-b5e6-96231b3b80d8
Since the relocation iterator walks only the relocations in one section, we
can just use a pointer and avoid fetching information about the section at
every reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180189 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
I will remove the isBigEndianHost function once I update clang.
The ifdef logic is designed to
* not use configure/cmake to avoid breaking -arch i686 -arch ppc.
* default to little endian
* be as small as possible
It looks like sys/endian.h is the preferred header on most modern BSD systems,
but it is better to change this in a followup patch as machine/endian.h is
available on FreeBSD, OpenBSD, NetBSD and OS X.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179527 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
Original message:
Print more information about relocations.
With this patch llvm-readobj now prints if a relocation is pcrel, its length,
if it is extern and if it is scattered.
It also refactors the code a bit to use bit fields instead of shifts and
masks all over the place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179345 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch llvm-readobj now prints if a relocation is pcrel, its length,
if it is extern and if it is scattered.
It also refactors the code a bit to use bit fields instead of shifts and
masks all over the place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179294 91177308-0d34-0410-b5e6-96231b3b80d8
It was returning the loaded address of the section containing the relocation,
which really doesn't seem to be the intent of this function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179255 91177308-0d34-0410-b5e6-96231b3b80d8
These were the last missing forwarding functions. Also consistently use
the forwarding functions instead of using MachOObj directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178992 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
Improve performance of iterating over children and accessing the member file
buffer by caching the file size and moving code out to the header.
This also makes getBuffer return a StringRef instead of a MemoryBuffer. Both
fixing a memory leak and removing a malloc.
This takes getBuffer from ~10% of the time in lld to unmeasurable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174272 91177308-0d34-0410-b5e6-96231b3b80d8
politely report it instead of running into llvm_unreachable.
Also patch llvm-dwarfdump to actually check whether the file it's attempting to
dump is a valid object file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173489 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
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile owns a MachOObj, but never frees it. Both MachOObjectFile
and MachOObj want to own the MemoryBuffer, though, so we have to be careful
and give them each one of their own.
Thanks to Greg Clayton, Eric Christopher and Michael Spencer for helping
figure out what's going wrong here.
rdar://12561773
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168923 91177308-0d34-0410-b5e6-96231b3b80d8
Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.
Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.
data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"
The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.
rdar://11459456
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157062 91177308-0d34-0410-b5e6-96231b3b80d8
