| Age | Commit message (Collapse) | Author |
|---|
|
llvm-svn: 201108
|
|
llvm-svn: 200800
|
|
None of the object formats require extra parsing to compute these flags,
so the method cannot fail.
llvm-svn: 200574
|
|
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.
llvm-svn: 200488
|
|
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
|
|
This allows llvm-ar to mmap the input files only once.
llvm-svn: 200040
|
|
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.
llvm-svn: 199770
|
|
Patch by Marius Wachtler.
llvm-svn: 196560
|
|
llvm-svn: 193933
|
|
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.
llvm-svn: 193912
|
|
It is mentioned in the LLVM coding standard that _begin() and _end() suffixes
should be used.
llvm-svn: 191569
|
|
llvm-svn: 189728
|
|
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
|
llvm-svn: 189315
|
|
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.
llvm-svn: 189314
|
|
llvm-svn: 188852
|
|
this records relocation entries in the mach-o object file
for PIC code generation.
tested on powerpc-darwin8, validated against darwin otool -rvV
llvm-svn: 188004
|
|
llvm-svn: 187698
|
|
llvm-svn: 186886
|
|
llvm-svn: 186885
|
|
llvm-svn: 184191
|
|
from the LC_DATA_IN_CODE load command. And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.
I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.
rdar://11791371
llvm-svn: 183424
|
|
In ELF (as in MachO), not all relocations point to symbols. Represent this
properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj
ELF's dumper to handle relocatios without symbols.
llvm-svn: 183284
|
|
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.
llvm-svn: 181843
|
|
It was only implemented for ELF where it collected the Addend, so this
patch also renames it to getRelocationAddend.
llvm-svn: 181502
|
|
llvm-svn: 180790
|
|
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).
llvm-svn: 180736
|
|
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.
llvm-svn: 180624
|
|
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.
llvm-svn: 180262
|
|
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
|
|
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.
llvm-svn: 180214
|
|
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.
llvm-svn: 180194
|
|
llvm-svn: 180190
|
|
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.
llvm-svn: 180189
|
|
llvm-svn: 179851
|
|
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.
llvm-svn: 179848
|
|
We are still able to handle mixed endian objects by swapping one struct at a
time.
llvm-svn: 179778
|
|
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
|
|
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.
llvm-svn: 179345
|
|
llvm-svn: 179303
|
|
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.
llvm-svn: 179294
|
|
It was returning the loaded address of the section containing the relocation,
which really doesn't seem to be the intent of this function.
llvm-svn: 179255
|
|
llvm-svn: 179179
|
|
For now they are still only used as little endian.
llvm-svn: 179147
|
|
For now it is templated only on being 64 or 32 bits. I will add little/big
endian next.
llvm-svn: 179097
|
|
llvm-svn: 179076
|
|
Use it when we don't need to know if we have a 32 or 64 bit SymbolTableEntry.
llvm-svn: 179074
|
|
Use it to share code and when we don't need to know if we have a 32 or 64
bit Section.
llvm-svn: 179072
|
|
llvm-svn: 179051
|
|
llvm-svn: 179048
|
