[LLVMdev] [cfe-dev] exc_bad_instruction on arm
Anton Smirnov
dev at antonsmirnov.name
Wed Sep 17 12:11:39 PDT 2014
I've also tried the next combination:
true, // ForceInterpreter
false, // UseMCJIT
and ios app just crashed with no output
2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> 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/81616956/attachment.html>
More information about the llvm-dev
mailing list