The assumption that the target address for the relocation will always be
sizeof(intptr_t) and will always contain an addend for the relocation
value is very wrong. Default to no addend for now.
rdar://12157052
llvm-svn: 163765
When comparing to the macho relocation type enum value, make sure we're only
comparing against the bits in the RelType that correspond.
llvm-svn: 163764
No new tests are added.
All tests in ExecutionEngine/MCJIT that have been failing pass after this patch
is applied (when "make check" is done on a mips board).
Patch by Petar Jovanovic.
llvm-svn: 162135
- Improved parameter names for clarity
- Added comments
- emitCommonSymbols should return void because its return value is not being
used anywhere
- Attempt to reduce the usage of the RelocationValueRef type. Restricts it
for a single goal and may serve as a step for eventual removal.
llvm-svn: 155908
- There's no point having a different type for the local and global symbol
tables.
- Renamed SymbolTable to GlobalSymbolTable to clarify the intention
- Improved const correctness where relevant
llvm-svn: 155898
relocations are resolved. It's much more reasonable to do this decision when
relocations are just being added - we have all the information at that point.
Also a bit of renaming and extra comments to clarify extensions.
llvm-svn: 155819
- Add comments
- Change field names to be more reasonable
- Fix indentation and naming to conform to coding conventions
- Remove unnecessary includes / replace them by forward declatations
llvm-svn: 155815
the MCJIT execution engine.
The GDB JIT debugging integration support works by registering a loaded
object image with a pre-defined function that GDB will monitor if GDB
is attached. GDB integration support is implemented for ELF only at this
time. This integration requires GDB version 7.0 or newer.
Patch by Andy Kaylor!
llvm-svn: 154868
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
1. The main works will made in the RuntimeDyLdImpl with uses the ObjectFile class. RuntimeDyLdMachO and RuntimeDyLdELF now only parses relocations and resolve it. This is allows to make improvements of the RuntimeDyLd more easily. In addition the support for COFF can be easily added.
2. Added ARM relocations to RuntimeDyLdELF.
3. Added support for stub functions for the ARM, allowing to do a long branch.
4. Added support for external functions that are not loaded from the object files, but can be loaded from external libraries. Now MCJIT can correctly execute the code containing the printf, putc, and etc.
5. The sections emitted instead functions, thanks Jim Grosbach. MemoryManager.startFunctionBody() and MemoryManager.endFunctionBody() have been removed.
6. MCJITMemoryManager.allocateDataSection() and MCJITMemoryManager. allocateCodeSection() used JMM->allocateSpace() instead of JMM->allocateCodeSection() and JMM->allocateDataSection(), because I got an error: "Cannot allocate an allocated block!" with object file contains more than one code or data sections.
llvm-svn: 153754
relocations. The algorithm is the same as
that for x86_64. Scattered relocations, a
feature present in i386 but not on x86_64,
are not yet supported.
llvm-svn: 153466
(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.
The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.
When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.
llvm-svn: 153241
relocations (i.e., pieces of data whose addresses
are referred to elsewhere in the binary image) and
update the references when the section containing
the relocations moves. The way this works is that
there is a map from section IDs to lists of
relocations.
Because the relocations are associated with the
section containing the data being referred to, they
are updated only when the target moves. However,
many data references are relative and also depend
on the location of the referrer.
To solve this problem, I introduced a new data
structure, Referrer, which simply contains the
section being referred to and the index of the
relocation in that section. These referrers are
associated with the source containing the
reference that needs to be updated, so now
regardless of which end of the relocation moves,
the relocation will now be updated correctly.
llvm-svn: 153147
code that will be relocated into another memory space.
Now when relocations are resolved, the address of
the relocation in the host memory (where the JIT is)
is passed separately from the address that the
relocation will be at in the target memory (where
the code will run).
llvm-svn: 152264
- Use unsigned literals when the desired result is unsigned. This mostly allows unsigned/signed mismatch warnings to be less noisy even if they aren't on by default.
- Remove misplaced llvm_unreachable.
- Add static to a declaration of a function on MSVC x86 only.
- Change some instances of calling a static function through a variable to simply calling that function while removing the unused variable.
llvm-svn: 150364
to what's done for MachO and COFF. This allows advanced uses of the class to
be implemented outside the Object library. In particular, the DyldELFObject
subclass is now moved into its logical home - ExecutionEngine/RuntimeDyld.
This patch was reviewed by Michael Spencer.
llvm-svn: 150327
The MachO file stores section alignment as log2(alignment-in-bytes). The
allocation routines want the raw alignment-in-bytes value, so adjust
for that.
llvm-svn: 148604
Move to a by-section allocation and relocation scheme. This allows
better support for sections which do not contain externally visible
symbols.
Flesh out the relocation address vs. local storage address separation a
bit more as well. Remote process JITs use this to tell the relocation
resolution code where the code will live when it executes.
The startFunctionBody/endFunctionBody interfaces to the JIT and the
memory manager are deprecated. They'll stick around for as long as the
old JIT does, but the MCJIT doesn't use them anymore.
llvm-svn: 148258
Jim Grosbach