RTDyldMemoryManager, regardless of whether it thinks they're "required for
execution".
Currently, RuntimeDyld only passes sections that are "required for execution"
to the RTDyldMemoryManager, and takes "required for execution" to mean exactly
"contains symbols or relocations". There are two problems with this:
(1) It can drop sections with anonymous data that is referenced by code.
(2) It leaves the JIT client no way to inspect interesting sections that aren't
actually required to run the program (e.g dwarf sections).
A test case is still in the works.
Future work: We may want to replace this with a generic section filtering
mechanism, but that will require more consideration. For now, this flag at least
allows clients to volunteer to do the filtering themselves.
Fixes <rdar://problem/15177691>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204398 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
already lived there and it is where it belongs -- this is the in-memory
debug location representation.
This is just cleanup -- Modules can actually cope with this, but that
doesn't make it right. After chatting with folks that have out-of-tree
stuff, going ahead and moving the rest of the headers seems preferable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202960 91177308-0d34-0410-b5e6-96231b3b80d8
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
Move the test for this class into the IR unittests as well.
This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202821 91177308-0d34-0410-b5e6-96231b3b80d8
required for all sections in a module. This can be useful when targets or
code-models place strict requirements on how sections must be laid out
in memory.
If RTDyldMemoryManger::needsToReserveAllocationSpace() is overridden to return
true then the JIT will call the following method on the memory manager, which
can be used to preallocate the necessary memory.
void RTDyldMemoryManager::reserveAllocationSpace(uintptr_t CodeSize,
uintptr_t DataSizeRO,
uintptr_t DataSizeRW)
Patch by Vaidas Gasiunas. Thanks very much Viadas!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201259 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the target analysis passes (usually TargetTransformInfo) to the
codgen pipeline. We also expose now the AddAnalysisPasses method through the C
API, because the optimizer passes would also benefit from better target-specific
cost models.
Reviewed by Andrew Kaylor
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199926 91177308-0d34-0410-b5e6-96231b3b80d8
I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198737 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
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
Support for exception handling in the legacy JIT was removed in r181354 and
this code was dead since then.
Thanks to Yaron Keren for noticing it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192101 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful for the memory managers that are allocating a section to know what the name of the section is.
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about
what each allocation is for. This allows clients that supply their own memory managers to do this.
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM
client.
This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that
it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory
management C API).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191804 91177308-0d34-0410-b5e6-96231b3b80d8
Tests to follow.
PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191722 91177308-0d34-0410-b5e6-96231b3b80d8
the C API to provide their own way of allocating JIT memory (both code
and data) and finalizing memory permissions (page protections, cache
flush).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182448 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
This is a fixed version of r182407 and r182411. That first revision
broke builds because I forgot to move the conditional includes of
various POSIX headers from SectionMemoryManager into
RTDyldMemoryManager. Those includes are necessary because of how
getPointerToNamedFunction works around the glibc libc_nonshared.a thing.
The latter revision still broke things because I forgot to include
llvm/Config/config.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182418 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
This is a fixed version of r182407. That revision broke builds because I
forgot to move the conditional includes of various POSIX headers from
SectionMemoryManager into RTDyldMemoryManager. Those includes are
necessary because of how getPointerToNamedFunction works around the
glibc libc_nonshared.a thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182411 91177308-0d34-0410-b5e6-96231b3b80d8
the C API to provide their own way of allocating JIT memory (both code
and data) and finalizing memory permissions (page protections, cache
flush).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182408 91177308-0d34-0410-b5e6-96231b3b80d8
libExecutionEngine. Move method implementations that aren't specific to
allocation out of SectionMemoryManager and into RTDyldMemoryManager.
This is in preparation for exposing RTDyldMemoryManager through the C
API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182407 91177308-0d34-0410-b5e6-96231b3b80d8
the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182085 91177308-0d34-0410-b5e6-96231b3b80d8
EngineBuilder interface required a JITMemoryManager even if it was being used
to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager.
Consequently, the SectionMemoryManager, which is meant for MCJIT, derived
from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager
methods that weren't relevant to the MCJIT.
This patch fixes the situation: it teaches the EngineBuilder that
RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's
appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if
we're using the MCJIT. This allows us to remove the stub methods from
SectionMemoryManager, and make SectionMemoryManager a direct subtype of
RTDyldMemoryManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181820 91177308-0d34-0410-b5e6-96231b3b80d8
This gets exception handling working on ELF and Macho (x86-64 at least).
Other than the EH frame registration, this patch also implements support
for GOT relocations which are used to locate the personality function on
MachO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181167 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
AKA: Recompile *ALL* the source code!
This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
The SectionMemoryManager now supports (and requires) applying section-specific page permissions. Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code.
See r168718 for changes from the previous implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168721 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the interface to expose events from MCJIT when an object is emitted or freed and implements the MCJIT functionality to send those events. The IntelJITEventListener implementation is left empty for now. It will be fleshed out in a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167475 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress). In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved. To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167400 91177308-0d34-0410-b5e6-96231b3b80d8
* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
people want -- it starts a new paragraph);
* use \param instead of \arg to document parameters in order to be consistent
with the rest of the codebase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163902 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure to return a pointer into the target memory, not the local memory.
Often they are the same, but we can't assume that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163217 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153754 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary if the client wants to be able to mutate TargetOptions (for example, fast FP math mode) after the initial creation of the ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153342 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153241 91177308-0d34-0410-b5e6-96231b3b80d8
1. Declare a virtual function getPointerToNamedFunction() in JITMemoryManager
2. Move the implementation of getPointerToNamedFunction() form JIT/MCJIT to DefaultJITMemoryManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153205 91177308-0d34-0410-b5e6-96231b3b80d8
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.
This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152620 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148258 91177308-0d34-0410-b5e6-96231b3b80d8
The OptLevel is now redundant with the TargetMachine*.
And selectTarget() isn't really JIT-specific and could probably
get refactored into one of the lower level libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146355 91177308-0d34-0410-b5e6-96231b3b80d8
It was getting ignored after r144788.
Also fix an accidental implicit cast from the OptLevel enum
to an optional bool argument. MSVC warned on this, but gcc
didn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145633 91177308-0d34-0410-b5e6-96231b3b80d8
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135580 91177308-0d34-0410-b5e6-96231b3b80d8
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135468 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131317 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131316 91177308-0d34-0410-b5e6-96231b3b80d8
