[LLVMdev] [cfe-dev] exc_bad_instruction on arm
Anton Smirnov
dev at antonsmirnov.name
Wed Sep 17 11:47:57 PDT 2014
Hey.
I've checked out LLVM/Clang 3.5 and modified my static libs source code to
use the latest llvm/clang sources.
Also i'm trying triple ""arm64-apple-ios7.0"" now as it's wriiten in 3.5
release notes.
I'm having simple (and pretty useless) source file:
int main(int count, const char **args) {
const char *c = "hello world";
return 1 + 5;
}
i using the next llc params:
const char *cmd[] = {
"clang",
"-cc1",
"-triple",
"arm64-apple-ios7.0",
"-emit-llvm",
"-disable-free",
"-main-file-name",
[cppShortFile UTF8String], // "hw.cpp"
"-mrelocation-model",
"pic",
"-pic-level",
"2",
"-mdisable-fp-elim",
"-masm-verbose",
"-target-linker-version",
"236.3",
"-v",
"-coverage-file",
[llFile UTF8String],
//"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll"
"-resource-dir",
[[[ASPathHolder sharedHolder] tempFolder] UTF8String],
"-stdlib=libc++",
"-fdeprecated-macro",
"-fdebug-compilation-dir",
[[[ASPathHolder sharedHolder] tempFolder] UTF8String],
"-ferror-limit",
"19",
"-fmessage-length",
"0",
"-stack-protector",
"1",
"-mstackrealign",
"-fcxx-exceptions",
"-fexceptions",
"-fdiagnostics-show-option",
"-vectorize-slp",
"-mfloat-abi",
"soft",
"-o",
[llFile UTF8String], //
/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.ll
"-x",
"c++",
[cppFile UTF8String]
//"/private/var/mobile/Applications/175ECA7F-3175-4AC9-971C-85272F5492C4/tmp/hw.cpp"
};
and i'm getting the next .ll code (which seems to be pretty close or
exactly the same as previous one):
; ModuleID =
'/var/mobile/Applications/53D60D11-DF93-4129-AD97-B96424D165B5/Documents/projects/calc/calc.cpp'
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-ios7.0"
@.str = private unnamed_addr constant [12 x i8] c"hello world\00", align 1
; Function Attrs: nounwind ssp
define i32 @main(i32 %count, i8** %args) #0 {
entry:
%retval = alloca i32, align 4
%count.addr = alloca i32, align 4
%args.addr = alloca i8**, align 8
%c = alloca i8*, align 8
store i32 0, i32* %retval
store i32 %count, i32* %count.addr, align 4
store i8** %args, i8*** %args.addr, align 8
store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8**
%c, align 8
ret i32 6
}
attributes #0 = { nounwind ssp "less-precise-fpmad"="false"
"no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf"
"no-infs-fp-math"="false" "no-nans-fp-math"="false"
"stack-protector-buffer-size"="8" "unsafe-fp-math"="false"
"use-soft-float"="false" }
!llvm.ident = !{!0}
!0 = metadata !{metadata !"clang version 3.5.0 (tags/RELEASE_350/final
217949)"}
(Note changed triple and compiler version. Also note i'm not using
"target-cpu" argument now as "cortex-a8" is not supported for this triple).
Next i'm trying to interpret it (source code is copy-pasted from lli tool
source code):
// lli with my default arguments
int llvm_interpret(const char *ll_filename) {
std::string InputFile(ll_filename);
return llvm_interpret(
InputFile,
std::vector<std::string>(), // argv
false, // ForceInterpreter
false, // UseMCJIT
false, // DebugIR
false, // RemoteMCJIT
"", // ChildExecPath
' ', // OptLevel
std::string("arm64-apple-ios7.0"), // TargetTriple
std::string("arm64"), // MArch
std::string(), // MCPU
std::vector<std::string>(), // MAttrs
"main", // EntryFunc
std::vector<std::string>(), // ExtraModules
std::vector<std::string>(), // ExtraObjects
std::vector<std::string>(), // ExtraArchives
false, // EnableCacheManager
std::string(), // ObjectCacheDir
std::string(), // FakeArgv0
false, // DisableCoreFiles
false, // NoLazyCompilation
Reloc::PIC_, // RelocModel
CodeModel::JITDefault, // CMModel
true, // GenerateSoftFloatCalls
FloatABI::Soft, // FloatABIForCalls
false, // EmitJitDebugInfo
false // EmitJitDebugInfoToDisk
);
I'm getting the next error text:
*error creating EE: target does not support JIT code generation*
Ok, let's try using MCJIT as i was suggested.
Now change default value for "UseMCJIT" to true.
Then i have *EXC_BAD_ACCESS (code=260, address=0xd10083ff)* in
ExecutionEngine.cpp file:
return runFunction(Fn, GVArgs).IntVal.getZExtValue();
Tim? Anyone? I can provide source code and build scripts to reproduce the
case.
Regards, Anton.
2014-09-17 19:02 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> Both Clang/LLVM 3.4 -> Clang/LLVM 3.5
> And i will also try using MCJIT.
>
> 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
>
>> Hi, Tim.
>>
>> I've used Clang 3.4 final release and now i'm going to test it with 3.5
>> release (since i've read about arm64 improvements).
>> I will report my results.
>>
>> BTW, is it possible to get smth like "hello world" output even with apple
>> restrictions?
>>
>> Regards, Anton.
>>
>> 2014-09-17 18:42 GMT+06:00 Tim Northover <t.p.northover at gmail.com>:
>>
>>> Hi Anton,
>>>
>>> I've added the llvmdev list, since the issues you're seeing are coming
>>> from the backend, which is more their side.
>>>
>>> On 17 September 2014 08:43, Anton Smirnov <dev at antonsmirnov.name> wrote:
>>> > i've changed lli arguments to the next (instead of default):
>>> >
>>> > return llvm_interpret(
>>> > InputFile,
>>> > std::vector<std::string>(),
>>> > false, // ForceInterpreter
>>> > false, // UseMCJIT
>>> > [...]
>>> > Now i'm having:
>>> >
>>> > Unhandled instruction encoding format!
>>> > UNREACHABLE executed at
>>> >
>>> /Users/asmirnov/Documents/dev/src/llvm_34_ios/lib/Target/ARM/ARMCodeEmitter.cpp:547!
>>>
>>> This one at least is understandable. Your options imply (I couldn't
>>> find any "llvm_interpret" function, so there's some guesswork) that
>>> you're using the old JIT. That's been discouraged for a while, and
>>> it's been removed completely now in trunk.
>>>
>>> It's entirely possible it could randomly fall over (not all
>>> instructions are supported), and probably not even worth worrying
>>> about why. I'd just flip that "UseMCJIT" option.
>>>
>>> The interpreter failure you were seeing earlier is harder to explain
>>> (there are various options), but if we're lucky it won't happen in
>>> MCJIT mode. Then we don't have to worry about that one either.
>>>
>>> Cheers.
>>>
>>> Tim.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140918/5002f02f/attachment.html>
More information about the llvm-dev
mailing list