| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 179021
|
|
|
|
| |
llvm-svn: 178998
|
|
|
|
| |
llvm-svn: 178997
|
|
|
|
| |
llvm-svn: 178996
|
|
|
|
| |
llvm-svn: 178995
|
|
|
|
| |
llvm-svn: 178994
|
|
|
|
|
|
|
| |
These were the last missing forwarding functions. Also consistently use
the forwarding functions instead of using MachOObj directly.
llvm-svn: 178992
|
|
|
|
|
|
|
| |
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.
llvm-svn: 178991
|
|
|
|
|
|
| |
This avoids using MachOObject::getLoadCommandInfo.
llvm-svn: 178990
|
|
|
|
| |
llvm-svn: 178989
|
|
|
|
| |
llvm-svn: 178988
|
|
|
|
| |
llvm-svn: 178987
|
|
|
|
| |
llvm-svn: 178986
|
|
|
|
| |
llvm-svn: 178985
|
|
|
|
| |
llvm-svn: 178979
|
|
|
|
| |
llvm-svn: 178948
|
|
|
|
|
|
|
| |
This also required not using the RegisterStringTable API, which is also a
good thing.
llvm-svn: 178947
|
|
|
|
| |
llvm-svn: 178946
|
|
|
|
| |
llvm-svn: 178945
|
|
|
|
| |
llvm-svn: 178943
|