Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.
Keeping this ownership would make supporting IR inside native objects
particularly painful.
This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.
This patch introduces a few new types.
* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
for convenience functions that take a filename and return both the
buffer and the Binary using that buffer.
The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)
Changes made by clang-tidy with minor tweaks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215558 91177308-0d34-0410-b5e6-96231b3b80d8
Cleanup only: no functional change.
This patch makes RuntimeDyldMachO targets directly responsible for decoding
immediates, rather than letting them implement catch a callback from generic
code. Since this is a very target specific operation, it makes sense to let the
target-specific code drive it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215255 91177308-0d34-0410-b5e6-96231b3b80d8
be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reverts commits r215111, 215115, 215116, 215117, 215136.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215154 91177308-0d34-0410-b5e6-96231b3b80d8
C-style casts (and reinterpret_casts) result in implementation defined
values when a pointer is cast to a larger integer type. On some platforms
this was leading to bogus address computations in RuntimeDyldMachOAArch64.
This should fix http://llvm.org/PR20501.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215143 91177308-0d34-0410-b5e6-96231b3b80d8
I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.
Thanks to Lang Hames for making MCJIT a good replacement!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215111 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of moving out the data in a ErrorOr<std::unique_ptr<Foo>>, get
a reference to it.
Thanks to David Blaikie for the suggestion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214516 91177308-0d34-0410-b5e6-96231b3b80d8
We now (1) correctly decode the branch immediate, (2) modify the immediate to
corretly treat it as PC-rel, and (3) properly populate the stub entry.
Previously we had been doing each of these wrong.
<rdar://problem/17750739>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214285 91177308-0d34-0410-b5e6-96231b3b80d8
use in -verify mode.
This patch adds three hidden command line options to llvm-rtdyld:
-target-addr-start <start-addr> : Specify the start of the virtual address
space on the phony target.
-target-addr-end <end-addr> : Specify the end of the virtual address space
on the phony target.
-target-section-sep <sep> : Specify the separation (in bytes) between the
end of one section and the start of the next.
These options automatically default to sane values for the target platform. In
particular, they allow narrow (e.g. 32-bit, 16-bit) targets to be tested from
wider (e.g. 64-bit, 32-bit) hosts without overflowing pointers.
The section separation option defaults to zero, but can be set to a large number
(e.g. 1 << 32) to force large separations between sections in order to
stress-test large-code-model code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214255 91177308-0d34-0410-b5e6-96231b3b80d8
full paths for its first argument.
This allows us to remove the annoying sed lines in the test cases, and write
direct references to file names in stub_addr calls (rather than <filename>
placeholders).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214211 91177308-0d34-0410-b5e6-96231b3b80d8
Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and
invites bugs where only one is checked. In reality, the only legitimate
difference between the two (arm64 usually means iOS) is also present in the OS
part of the triple and that's what should be checked.
We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so
there aren't any LLVM-side test changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213743 91177308-0d34-0410-b5e6-96231b3b80d8
There's no reason to restrict this particular piece of RuntimeDyldChecker
functionality to +Asserts builds.
This should fix failures in MachO_x86-64_PIC_relocations.s on release bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213708 91177308-0d34-0410-b5e6-96231b3b80d8
RuntimeDyldChecker had been testing isalpha(Expr[0]) to recognise symbol tokens,
and throwing unrecognized token errors when it hit symbols with leading
underscores. This fixes that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213706 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a 'stub_addr' builtin that can be used to find the address
of the stub for a given (<file>, <section>, <symbol>) tuple. This address can be
used both to verify the contents of stubs (by loading from the returned address)
and to verify references to stubs (by comparing against the returned address).
Example (1) - Verifying stub contents:
Load 8 bytes (assuming a 64-bit target) from the stub for 'x' in the __text
section of f.o, and compare that value against the addres of 'x'.
# rtdyld-check: *{8}(stub_addr(f.o, __text, x) = x
Example (2) - Verifying references to stubs:
Decode the immediate of the instruction at label 'l', and verify that it's
equal to the offset from the next instruction's PC to the stub for 'y' in the
__text section of f.o (i.e. it's the correct PC-rel difference).
# rtdyld-check: decode_operand(l, 4) = stub_addr(f.o, __text, y) - next_pc(l)
l:
movq y@GOTPCREL(%rip), %rax
Since stub inspection requires cooperation with RuntimeDyldImpl this patch
pimpl-ifies RuntimeDyldChecker. Its implementation is moved in to a new class,
RuntimeDyldCheckerImpl, that has access to the definition of RuntimeDyldImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213698 91177308-0d34-0410-b5e6-96231b3b80d8
Factor out the addend encoding into a helper function and simplify the
processRelocationRef.
Also add a few simple rtdyld tests. More tests to come once GOTs can be tested too.
Related to <rdar://problem/17768539>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213689 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the required functionality to decode the immediate encoded in an
instruction that is referenced in a relocation entry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213688 91177308-0d34-0410-b5e6-96231b3b80d8
In MachO for AArch64 it is possible to have an explicit addend defined by
the ARM64_RELOC_ADDEND relocation or having an addend encoded within the
instruction. Only one of them are allowed per relocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213687 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables the new ELFv2 ABI in the runtime dynamic loader.
The loader has to implement the following features:
- In the ELFv2 ABI, do not look up a function descriptor in .opd, but
instead use the local entry point when resolving a direct call.
- Update the TOC restore code to use the new TOC slot linkage area
offset.
- Create PLT stubs appropriate for the ELFv2 ABI.
Note that this patch also adds common-code changes. These are necessary
because the loader must check the newly added ELF flags: the e_flags
header bits encoding the ABI version, and the st_other symbol table
entry bits encoding the local entry point offset. There is currently
no way to access these, so I've added ObjectFile::getPlatformFlags and
SymbolRef::getOther accessors.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213491 91177308-0d34-0410-b5e6-96231b3b80d8
getBasicRelocationEntry to use this rather than 'memcpy' to get the
relocation addend. Targets with non-trivial addend encodings (E.g. AArch64) can
override decodeAddend to handle immediates with interesting encodings.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213435 91177308-0d34-0410-b5e6-96231b3b80d8
RelocationEntry.
No test case yet, as this primarily hits GOT entries, which RuntimeDyldChecker
can't examine yet. I'm actively working on features that will enable us to
test this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213408 91177308-0d34-0410-b5e6-96231b3b80d8
relaxed in the big RuntimeDyldMachO cleanup of r213293.
No test case yet - this was found via inspection and there's no easy way to test
GOT alignment in RuntimeDyldChecker at the moment. I'm working on adding support
for this now, and hope to have a test case for this soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213331 91177308-0d34-0410-b5e6-96231b3b80d8
This optional dependency on the udis86 library was added some time back to aid
JIT development, but doesn't make much sense to link into LLVM binaries these
days.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213300 91177308-0d34-0410-b5e6-96231b3b80d8
The previous implementation of RuntimeDyldMachO mixed logic for all targets
within a single class, creating problems for readability, maintainability, and
performance. To address these issues, this patch strips the RuntimeDyldMachO
class down to just target-independent functionality, and moves all
target-specific functionality into target-specific subclasses RuntimeDyldMachO.
The new class hierarchy is as follows:
class RuntimeDyldMachO
Implemented in RuntimeDyldMachO.{h,cpp}
Contains logic that is completely independent of the target. This consists
mostly of MachO helper utilities which the derived classes use to get their
work done.
template <typename Impl>
class RuntimeDyldMachOCRTPBase<Impl> : public RuntimeDyldMachO
Implemented in RuntimeDyldMachO.h
Contains generic MachO algorithms/data structures that defer to the Impl class
for target-specific behaviors.
RuntimeDyldMachOARM : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOARM>
RuntimeDyldMachOARM64 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOARM64>
RuntimeDyldMachOI386 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOI386>
RuntimeDyldMachOX86_64 : public RuntimeDyldMachOCRTPBase<RuntimeDyldMachOX86_64>
Implemented in their respective *.h files in lib/ExecutionEngine/RuntimeDyld/MachOTargets
Each of these contains the relocation logic specific to their target architecture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213293 91177308-0d34-0410-b5e6-96231b3b80d8
When a RuntimeDyldChecker test requests an invalid operand for an instruction,
print the decoded instruction to aid diagnosis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213202 91177308-0d34-0410-b5e6-96231b3b80d8
The registration scheme used in r211652 violated the read-only contract of
MemoryBuffer. This caused crashes in llvm-rtdyld where macho objects were backed
by read-only mmap'd memory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213086 91177308-0d34-0410-b5e6-96231b3b80d8
reading MachO files magic numbers in RuntimeDyld.
This is required now that we're testing cross-platform JITing (via
RuntimeDyldChecker), and should fix some issues that David Fang has seen on PPC
builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213012 91177308-0d34-0410-b5e6-96231b3b80d8
Test cases to follow once RuntimeDyldChecker supports introspection of stubs.
Fixes <rdar://problem/17648000>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212859 91177308-0d34-0410-b5e6-96231b3b80d8
The compiler often emits assembler-local labels (beginning with 'L') for use in
relocation expressions, however these aren't included in the object files.
Teach RuntimeDyldChecker to warn the user if they try to use one of these in an
expression, since it will never work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212777 91177308-0d34-0410-b5e6-96231b3b80d8
ForceInterpreter=false shouldn't disable the interpreter completely because it
can still be necessary to interpret if the target doesn't support JIT.
No obvious way to test this in LLVM, but this matches what
LLVMCreateExecutionEngineForModule() does and fixes the clang-interpreter
example in the clang source tree which uses the ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212086 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a "-verify" mode to the llvm-rtdyld utility. In verify mode,
llvm-rtdyld will test supplied expressions against the linked program images
that it creates in memory. This scheme can be used to verify the correctness
of the relocation logic applied by RuntimeDyld.
The expressions to test will be read out of files passed via the -check option
(there may be more than one of these). Expressions to check are extracted from
lines of the form:
# rtdyld-check: <expression>
This system is designed to fit the llvm-lit regression test workflow. It is
format and target agnostic, and supports verification of images linked for
remote targets. The expression language is defined in
llvm/include/llvm/RuntimeDyldChecker.h . Examples can be found in
test/ExecutionEngine/RuntimeDyld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211956 91177308-0d34-0410-b5e6-96231b3b80d8
Current PPC64 RuntimeDyld code to handle TOC relocations has two
problems:
- With recent linkers, in addition to the relocations that implicitly
refer to the TOC base (R_PPC64_TOC*), you can now also use the .TOC.
magic symbol with any other relocation to refer to the TOC base
explicitly. This isn't currently used much in ELFv1 code (although
it could be), but it is essential in ELFv2 code.
- In a complex JIT environment with multiple modules, each module may
have its own .toc section, and TOC relocations in one module must
refer to *its own* TOC section. The current findPPC64TOC implementation
does not correctly implement this; in fact, it will always return the
address of the first TOC section it finds anywhere. (Note that at the
time findPPC64TOC is called, we don't even *know* which module the
relocation originally resided in, so it is not even possible to fix
this routine as-is.)
This commit fixes both problems by handling TOC relocations earlier, in
processRelocationRef. To do this, I've removed the findPPC64TOC routine
and replaced it by a new routine findPPC64TOCSection, which works
analogously to findOPDEntrySection in scanning the sections of the
ObjImage provided by its caller, processRelocationRef. This solves the
issue of finding the correct TOC section associated with the current
module.
This makes it straightforward to implement both R_PPC64_TOC relocations,
and relocations explicitly refering to the .TOC. symbol, directly in
processRelocationRef. There is now a new problem in implementing the
R_PPC64_TOC16* relocations, because those can now in theory involve
*three* different sections: the relocation may be applied in section A,
refer explicitly to a symbol in section B, and refer implicitly to the
TOC section C. The final processing of the relocation thus may only
happen after all three of these sections have been assigned final
addresses. There is currently no obvious means to implement this in
its general form with the common-code RuntimeDyld infrastructure.
Fortunately, ppc64 code usually makes no use of this most general form;
in fact, TOC16 relocations are only ever generated by LLVM for symbols
residing themselves in the TOC, which means "section B" == "section C"
in the above terminology. This special case can easily be handled with
the current infrastructure, and that is what this patch does.
[ Unhandled cases result in an explicit error, unlike the current code
which silently returns the wrong TOC base address ... ]
This patch makes the JIT work on both BE and LE (ELFv2 requires
additional patches, of course), and allowed me to successfully run
complex JIT scenarios (via mesa/llvmpipe).
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211885 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the buffer ownership on error conditions very natural. The buffer
is only moved out of the argument if an object is constructed that now
owns the buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211546 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 1f502bd9d7, due to
GCC / MinGW's lack of support for C++11 threading.
It's possible this will go back in after we come up with a
reasonable solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211401 91177308-0d34-0410-b5e6-96231b3b80d8
When RuntimeDyldELF creates stub functions, it needs to install
relocations that will resolve to the final address of the target
routine. Since those are 16-bit relocs, they need to be applied to the
least-significant halfword of the instruction. On big-endian ppc64,
this means that addresses have to be adjusted by 2, which is what the
code currently does.
However, on a little-endian system, the address must *not* be adjusted;
the least-significant halfword is the first one. This patch updates the
RuntimeDyldELF code to take the target byte order into account.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211384 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for several missing PPC64 relocations in the
straight-forward manner to RuntimeDyldELF.cpp.
Note that this actually fixes a failure of a large-model test case on
PowerPC, allowing the XFAIL to be removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211382 91177308-0d34-0410-b5e6-96231b3b80d8
This change has a bit of a trickle down effect due to the fact that
there are a number of derived implementations of ExecutionEngine,
and that the mutex is not tightly encapsulated so is used by other
classes directly.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211214 91177308-0d34-0410-b5e6-96231b3b80d8
This pattern loses some of its usefulness when the mutex type is
statically polymorphic as opposed to runtime polymorphic, as
swapping out the mutex type requires changing a significant number
of function parameters, and templatizing the function parameter
requires the methods to be defined in the headers.
Furthermore, if LLVM is compiled with threads disabled then there
may even be no mutex to acquire anyway, so it should not be up to
individual APIs to know whether or not acquiring a mutex is required
to use those APIs to begin with. It should be up to the user of the
API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211125 91177308-0d34-0410-b5e6-96231b3b80d8
These parameters are intended to serve as sort of a contract that
you cannot access the functions outside of a mutex. However, the
entire JIT class cannot be accessed outside of a mutex anyway, and
all methods acquire a lock as soon as they are entered. Since the
containing class already is not intended to be thread-safe, it only
serves to add code clutter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211071 91177308-0d34-0410-b5e6-96231b3b80d8
These were being used as unreferenced parameters to enforce that
the methods must not be called without holding a mutex, but all
of the methods in question were internal, and the methods were
only exposed through an interface whose entire purpose was to
serialize access to these structures, so expecting the methods
to be accessed under a mutex is reasonable enough.
Reviewed by: blaikie
Differential Revision: http://reviews.llvm.org/D4162
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211054 91177308-0d34-0410-b5e6-96231b3b80d8
Now that we have c++11, even things like ErrorOr<std::unique_ptr<...>> are
easy to use.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211033 91177308-0d34-0410-b5e6-96231b3b80d8
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is
up to MC (or the system assembler) to decide if that expression is valid or not.
This reduces our ability to diagnose invalid uses and how early we can spot
them, but it also lets us do things like
@test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32),
i32 ptrtoint (i32* @bar to i32)) to i32*)
An important implication of this patch is that the notion of aliased global
doesn't exist any more. The alias has to encode the information needed to
access it in its metadata (linkage, visibility, type, etc).
Another consequence to notice is that getSection has to return a "const char *".
It could return a NullTerminatedStringRef if there was such a thing, but when
that was proposed the decision was to just uses "const char*" for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210062 91177308-0d34-0410-b5e6-96231b3b80d8
This patch updates IntelJITEventListener.cpp to account for revision 206654, which removed some methods from DILineInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209989 91177308-0d34-0410-b5e6-96231b3b80d8
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209952 91177308-0d34-0410-b5e6-96231b3b80d8
This commit starts with a "git mv ARM64 AArch64" and continues out
from there, renaming the C++ classes, intrinsics, and other
target-local objects for consistency.
"ARM64" test directories are also moved, and tests that began their
life in ARM64 use an arm64 triple, those from AArch64 use an aarch64
triple. Both should be equivalent though.
This finishes the AArch64 merge, and everyone should feel free to
continue committing as normal now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209577 91177308-0d34-0410-b5e6-96231b3b80d8
We do all of our address arithmetic in 64-bit, and operations involving
logically negative 32-bit offsets (actually represented as unsigned 64 bit ints)
often overflow into higher bits. The overflow check could be preserved by
casting to uint32 at the callsite for applyRelocationValue, but this would
eliminate the value of the check.
The right way to handle overflow in relocations is to make relocation processing
target specific, and compute the values for RelocationEntry objects in the
appropriate types (32-bit for 32-bit targets, 64-bit for 64-bit targets). This
is coming as part of the cleanup I'm working on.
This fixes another i386 regression test.
<rdar://problem/16889891>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209536 91177308-0d34-0410-b5e6-96231b3b80d8
i386.
This fixes two more MCJIT regression tests on i386:
ExecutionEngine/MCJIT/2003-05-06-LivenessClobber.ll
ExecutionEngine/MCJIT/2013-04-04-RelocAddend.ll
The implementation of processScatteredVANILLA is tasteless (*ba-dum-ching*),
but I'm working on a substantial tidy-up of RuntimeDyldMachO that should
improve things.
This patch also fixes a type-o in RuntimeDyldMachO::processSECTDIFFRelocation,
and teaches that method to skip over the PAIR reloc following the SECTDIFF.
<rdar://problem/16961886>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209478 91177308-0d34-0410-b5e6-96231b3b80d8
For GOT relocations the addend should modify the offset to the
GOT entry, not the value of the entry itself. Teach RuntimeDyldMachO
to do The Right Thing here.
Fixes <rdar://problem/16961886>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209154 91177308-0d34-0410-b5e6-96231b3b80d8
SECTDIFF relocations on 32-bit x86.
This fixes several of the MCJIT regression test failures that show up on 32-bit
builds.
<rdar://problem/16886294>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208635 91177308-0d34-0410-b5e6-96231b3b80d8
around RelocationEntries, rather than passing the same information via loose
arguments.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208375 91177308-0d34-0410-b5e6-96231b3b80d8
relocation entries it applies.
Prior to this patch, RuntimeDyldImpl::resolveExternalSymbols discarded
relocations for external symbols once they had been applied. This causes issues
if the client calls MCJIT::finalizeLoadedModules more than once, and updates the
location of any symbols in between (e.g. by calling MCJIT::mapSectionAddress).
No test case yet: None of our in-tree memory managers support moving sections
around. I'll have to hack up a dummy memory manager before I can write a unit
test.
Fixes <rdar://problem/16764378>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208257 91177308-0d34-0410-b5e6-96231b3b80d8
A bunch of switch cases were missing, not just for ARM64 but also for
AArch64_BE. I've fixed all those, but there's zero testing as
ExecutionEngine tests are disabled when crosscompiling and I don't
have a native platform available to test on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207626 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC 2013 provides std::make_unique, which it finds with ADL when one of
the parameters is std::unique_ptr, leading to an ambiguous overload.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207597 91177308-0d34-0410-b5e6-96231b3b80d8
Seems MSVC wants to be able to codegen inline-definitions of virtual
functions even in TUs that don't define the key function - and it's well
within its rights to do so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207581 91177308-0d34-0410-b5e6-96231b3b80d8
This starts in MCJIT::getSymbolAddress where the
unique_ptr<object::Binary> is release()d and (after a cast) passed to a
single caller, MCJIT::addObjectFile.
addObjectFile calls RuntimeDyld::loadObject.
RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile
And the pointer is never owned at this point. I say this point, because
the alternative codepath, RuntimeDyldMachO::createObjectFile certainly
does take ownership, so this seemed like a good hint that this was a/the
right place to take ownership.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207580 91177308-0d34-0410-b5e6-96231b3b80d8
