| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
These should really be templated like ELF, but this is a start.
llvm-svn: 178896
|
|
|
|
| |
llvm-svn: 178894
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 178875
|
|
|
|
|
|
|
|
| |
our bitwise compare is equal to the field we're looking for.
Noticed on inspection.
llvm-svn: 176296
|
|
|
|
|
|
| |
function is called with a signed char argument, in order to avoid assertions in Windows Debug configuration.
llvm-svn: 175006
|
|
|
|
| |
llvm-svn: 174079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :-)
llvm-svn: 170838
|
|
|
|
| |
llvm-svn: 170547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 170545
|
|
|
|
| |
llvm-svn: 170349
|
|
|
|
|
|
| |
This reverts commit r170095 since it appears to be breaking the bots.
llvm-svn: 170105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 170095
|
|
|
|
| |
llvm-svn: 169963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
Should bring the buildbots back to life.
llvm-svn: 168935
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 168923
|
|
|
|
|
|
|
|
| |
Currently only implemented for ELF.
Patch by Amara Emerson.
llvm-svn: 166918
|
|
|
|
| |
llvm-svn: 165588
|
|
|
|
|
|
|
|
| |
determine whether or not a section is meant to be read-only. These functions will be used by the MCJIT RuntimeDyld to give hints to the memory manager during the object loading process in a future patch.
Patch by Ashok Thirumurthi.
llvm-svn: 165586
|
|
|
|
| |
llvm-svn: 157377
|
|
|
|
|
|
| |
the MachO spec.
llvm-svn: 155976
|
|
|
|
| |
llvm-svn: 154661
|
|
|
|
|
|
|
|
|
|
| |
of zero-initialized sections, virtual sections and common symbols
and preventing the loading of sections which are not required for
execution such as debug information.
Patch by Andy Kaylor!
llvm-svn: 154610
|
|
|
|
| |
llvm-svn: 154371
|
|
|
|
|
|
| |
Make Binary::TypeID more granular, to distinguish between ELF 32/64 little/big
llvm-svn: 152435
|
|
|
|
|
|
| |
Add ObjectFile::getLoadName() for retrieving the soname/installname of a shared object.
llvm-svn: 151845
|
|
|
|
|
|
|
|
|
| |
* Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile.
* Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable.
* Implement this new interface completely for ELF, leave stubs for COFF and MachO.
* Add 'llvm-readobj' tool for dumping ObjectFile information.
llvm-svn: 151785
|
|
|
|
|
|
|
|
|
| |
ST_Undefined. Implement these completely for ELF.
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).
llvm-svn: 151696
|
|
|
|
|
|
| |
and isWeak(), with a bitset of flags.
llvm-svn: 151670
|
|
|
|
|
|
|
|
| |
Add -D option to llvm-nm to dump dynamic symbols.
Patch by David Meyer.
llvm-svn: 151600
|
|
|
|
|
|
|
|
|
|
|
| |
- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.
llvm-svn: 145408
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Fixed ObjectFile functions:
- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.
llvm-svn: 145182
|
|
|
|
|
|
|
|
|
|
|
| |
- getSymbolOffset() renamed as getSymbolFileOffset()
- getSymbolFileOffset(), getSymbolAddress(), getRelocationAddress() returns same result for ELFObjectFile, MachOObjectFile and COFFObjectFile.
- added getRelocationOffset()
- fixed MachOObjectFile::getSymbolSize()
- fixed MachOObjectFile::getSymbolSection()
- fixed MachOObjectFile::getSymbolOffset() for symbols without section data.
llvm-svn: 145180
|
|
|
|
|
|
| |
relocation address, and we don't find a symbol table entry, try section begin addresses as well.
llvm-svn: 143151
|
|
|
|
|
|
| |
and x86_64 TLV relocations in MachO.
llvm-svn: 143140
|
|
|
|
| |
llvm-svn: 143051
|
|
|
|
|
|
| |
is reversed from what seems intuitive to me.
llvm-svn: 143035
|
|
|
|
|
|
| |
relocations, so that we can recognize scattered relocations.
llvm-svn: 143033
|
|
|
|
|
|
| |
require 33 bits of type info.
llvm-svn: 143032
|
|
|
|
| |
llvm-svn: 143031
|
|
|
|
| |
llvm-svn: 143011
|
|
|
|
| |
llvm-svn: 142970
|
|
|
|
|
|
|
|
| |
relocation entries that are used as additional information for other, real relocations, rather than being relocations themselves.
I'm not familiar enough with ELF or COFF to know if they should have any relocations marked hidden.
llvm-svn: 142961
|
|
|
|
| |
llvm-svn: 142938
|
|
|
|
|
|
| |
for x86 and x86_64 relocations with addends.
llvm-svn: 142875
|
|
|
|
| |
llvm-svn: 142852
|
|
|
|
| |
llvm-svn: 142840
|
|
|
|
| |
llvm-svn: 142673
|
|
|
|
| |
llvm-svn: 142317
|
|
|
|
| |
llvm-svn: 142316
|