maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/ExecutionEngine/MCJIT/2013-04-04-RelocAddend.ll

26 lines
471 B
LLVM
Raw Normal View History

Reinstate "Nuke the old JIT." Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
2014-09-03 06:28:02 +08:00
; RUN: %lli %s
Respect Addend when processing MCJIT relocations to local/global symbols. 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. llvm-svn: 178869
2013-04-05 21:29:04 +08:00
;
; Verify relocations to global symbols with addend work correctly.
;
; Compiled from this C code:
;
; int test[2] = { -1, 0 };
; int *p = &test[1];
;
; int main (void)
; {
; return *p;
; }
;
@test = global [2 x i32] [i32 -1, i32 0], align 4
[opaque pointer type] Add textual IR support for explicit type parameter to gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
2015-03-14 02:20:45 +08:00
@p = global i32* getelementptr inbounds ([2 x i32], [2 x i32]* @test, i64 0, i64 1), align 8
Respect Addend when processing MCJIT relocations to local/global symbols. 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. llvm-svn: 178869
2013-04-05 21:29:04 +08:00
define i32 @main() {
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%0 = load i32*, i32** @p, align 8
%1 = load i32, i32* %0, align 4
Respect Addend when processing MCJIT relocations to local/global symbols. 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. llvm-svn: 178869
2013-04-05 21:29:04 +08:00
ret i32 %1
}