At this time only Unix-based systems are supported. Windows has stubs and should re-route to the simulated mode.
Thanks to Sriram Murali for contributions to this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191843 91177308-0d34-0410-b5e6-96231b3b80d8
- Instead of setting the suffixes in a bunch of places, just set one master
list in the top-level config. We now only modify the suffix list in a few
suites that have one particular unique suffix (.ml, .mc, .yaml, .td, .py).
- Aside from removing the need for a bunch of lit.local.cfg files, this enables
4 tests that were inadvertently being skipped (one in
Transforms/BranchFolding, a .s file each in DebugInfo/AArch64 and
CodeGen/PowerPC, and one in CodeGen/SI which is now failing and has been
XFAILED).
- This commit also fixes a bunch of config files to use config.root instead of
older copy-pasted code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188513 91177308-0d34-0410-b5e6-96231b3b80d8
The change r187019 has fixed multiple relocations in dynamic linker for
MIPS, so now this test passes for MIPS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187053 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would read-modify-write the target bits when processing
relocations for the MCJIT. This had the problem that when relocations
were processed multiple times for the same object file (as they can
be), the result is not idempotent and the values became corrupted.
The solution to this is to take any bits used in the destination from
the pristine object file as LLVM emitted it.
This should fix PR16013 and remote MCJIT on ARM ELF targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182800 91177308-0d34-0410-b5e6-96231b3b80d8
lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182213 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the necessary configuration bits and #ifdef's to set up
the JIT/MCJIT test cases for SystemZ. Like other recent targets, we do
fully support MCJIT, but do not support the old JIT at all. Set up the
lit config files accordingly, and disable old-JIT unit tests.
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181207 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like symbol resolution is not working on cygwin, the test fails
because __gxx_personality_v0 is not found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181179 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
This removes dire warnings about AArch64 being unsupported and enables
the tests when appropriate on this platform.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181135 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes 2013-04-04-RelocAddend.ll. We don't have a testcase for non external
relocs with an Addend. I will try to write one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180767 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180736 91177308-0d34-0410-b5e6-96231b3b80d8
When the RuntimeDyldELF::processRelocationRef routine finds the target
symbol of a relocation in the local or global symbol table, it performs
a section-relative relocation:
Value.SectionID = lsi->second.first;
Value.Addend = lsi->second.second;
At this point, however, any Addend that might have been specified in
the original relocation record is lost. This is somewhat difficult to
trigger for relocations within the code section since they usually
do not contain non-zero Addends (when built with the default JIT code
model, in any case). However, the problem can be reliably triggered
by a relocation within the data section caused by code like:
int test[2] = { -1, 0 };
int *p = &test[1];
The initializer of "p" will need a relocation to "test + 4". On
platforms using RelA relocations this means an Addend of 4 is required.
Current code ignores this addend when processing the relocation,
resulting in incorrect execution.
Fixed by taking the Addend into account when processing relocations
to symbols found in the local or global symbol table.
Tested on x86_64-linux and powerpc64-linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178869 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the tests that behave differently on llvm-arm-linux buildbot
did so becase the triple wasn't set correctly to armv5, so we can
revert most of the special behaviour added previously. Some tests
still need the special treatment, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176243 91177308-0d34-0410-b5e6-96231b3b80d8
In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time. This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.
Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it. On architectures with a
single bitness, the host and process triples are identical. On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.
This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.
Differential Revision: http://llvm-reviews.chandlerc.com/D254
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172627 91177308-0d34-0410-b5e6-96231b3b80d8
