[LLVMdev] [cfe-dev] exc_bad_instruction on arm
Anton Smirnov
dev at antonsmirnov.name
Wed Sep 24 04:26:42 PDT 2014
any update on this?
2014-09-20 23:44 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> i've found why it was unavailable to find target - changed
> InitializeNative* to InitializeAll* methods (see lli source code).
>
> Anyway now i'm just getting exception as i wrote before.
> I've posted bug report (http://llvm.org/bugs/show_bug.cgi?id=21012) with:
> 1. full issue description
> 2. static library sources
> 3. lib build script
> 4. ios app that uses lib and where you can reproduce exception
>
> i hope my efforts will be awarded and someone fix it.
> also i will do my best in order to fix it ASAP.
>
> please contact me on email or skype (anton.smirnov.skype) to get more
> information if needed.
>
> Cheers,
> Anton.
>
> 2014-09-20 15:23 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
>
>> Hi, all.
>>
>> I've cloned llvm/clang trunk sources, configured with the same arguments
>> (as for llvm 3.5 release):
>>
>> --host=i386-apple-darwin11 --enable-threads=no --disable-threads
>> --disable-terminfo --enable-languages=c,c++ --enable-zlib=no --disable-zlib
>> --enable-targets=x86_64,arm,arm64
>>
>> After that i recompiled my interpreter lib (remember it's almost lli)
>> with code changed (i was surprised how it's changed since 3.5 release!)
>>
>> and created ios app that uses lib to test arm64 interpret issue. Then i
>> was surprised to get the next output:
>>
>> *libInterpreter: error creating EE: No available targets are compatible
>> with this triple, see -version for the available targets.*
>>
>> .ll file i'm trying to execute/interpret is almost as previous one (i've
>> added some code to it), but triple is the same:
>>
>> ; ModuleID = './test.cpp'
>>
>> target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
>>
>> target triple = "arm64-apple-ios7.0.0"
>>
>>
>> @.str = private unnamed_addr constant [12 x i8] c"hello world\00", align 1
>>
>>
>> ; Function Attrs: nounwind ssp
>>
>> define i32 @main(i32 %argc, i8** %argv) #0 {
>>
>> entry:
>>
>> %retval = alloca i32, align 4
>>
>> %argc.addr = alloca i32, align 4
>>
>> %argv.addr = alloca i8**, align 8
>>
>> %c = alloca i8*, align 8
>>
>> %a = alloca i32, align 4
>>
>> %b = alloca i32, align 4
>>
>> store i32 0, i32* %retval
>>
>> store i32 %argc, i32* %argc.addr, align 4
>>
>> store i8** %argv, i8*** %argv.addr, align 8
>>
>> store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8**
>> %c, align 8
>>
>> store i32 1, i32* %a, align 4
>>
>> %0 = load i32* %a, align 4
>>
>> %add = add nsw i32 %0, 6
>>
>> store i32 %add, i32* %b, align 4
>>
>> ret i32 3
>>
>> }
>>
>>
>> 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.6.0 (trunk 218116) (llvm/trunk
>> 218115)"}
>> I've compiled llvm_trunk (same source for host and compiled it using
>> -emit-llvm -S -c .. -o -target arm64-apple-ios7.0) so this target is
>> supported.
>> so i can't understand why i'm getting such error on the same code but on
>> arm (instead of my x86_64).
>>
>> What should i do?
>>
>> Regards, Anton.
>>
>> 2014-09-19 0:46 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
>>
>>> Hi, Lang.
>>>
>>> 2014-09-19 0:39 GMT+06:00 Lang Hames <lhames at gmail.com>:
>>>
>>>> Hi Anton,
>>>>
>>>> I don't follow what you're asking?
>>>>
>>>> For (1): You can compile c++ files to .ll files with clang - it seems
>>>> like you've already worked that out.
>>>>
>>>> For (2): What do you mean "supported at the moment"? In the 3.5 release
>>>> MCJIT is known to be broken for MachO/ARM. The Interpreter and the JIT are
>>>> both poorly tested (and seem to be broken, as you discovered). On the
>>>> development branch many of the bugs in MCJIT have been fixed, and I would
>>>> expect MCJIT to work for simple test cases. The JIT has been removed
>>>> entirely, and the Interpreter is still poorly tested. :)
>>>>
>>>
>>> You understood correctly what i was asking for.
>>>
>>>
>>>>
>>>> I look forward to checking out the bug reports.
>>>>
>>>
>>> Sure, just let me remove unneeded source code from my ios app and
>>> clean-up my build scripts for lli static lib.
>>>
>>>
>>>>
>>>> Good luck!
>>>>
>>>>
>>> Regards, Anton.
>>>
>>>
>>>> - Lang.
>>>>
>>>>
>>>>
>>>> On Thu, Sep 18, 2014 at 11:14 AM, Anton Smirnov <dev at antonsmirnov.name>
>>>> wrote:
>>>>
>>>>> Hi, Lang.
>>>>>
>>>>> Thanks for clarification. I will check out current branch tomorrow and
>>>>> report you back.
>>>>> Most likely i will create bug issue with cleaned sources for static
>>>>> lib and test ios app.
>>>>>
>>>>> Actually i'm not professional c++ dev so my question is - is there any
>>>>> chance to do the next:
>>>>> 1. compile .cpp code to .ll code (seems i already did it)
>>>>> 2. interpret .ll file by any supported at the moment way (i'm not sure
>>>>> if this can be done without relocations or smth like that)?
>>>>>
>>>>> I will do my best to assist you and i can test as soon as new commits
>>>>> are coming.
>>>>>
>>>>> Regards, Anton.
>>>>>
>>>>> 2014-09-18 23:00 GMT+06:00 Lang Hames <lhames at gmail.com>:
>>>>>
>>>>>> Hi Anton,
>>>>>>
>>>>>> Could you file a bug with your source and build scripts at
>>>>>> llvm.org/bugs and CC me on it?
>>>>>>
>>>>>> As Tim mentioned the old JIT was not well maintained in 3.4/3.5, and
>>>>>> has been removed from LLVM's mainline. Unfortunately MCJIT's support for
>>>>>> MachO/ARM didn't received much attention until recently either - MachO ARM
>>>>>> relocations are totally broken in 3.5, so any symbolic references in the
>>>>>> final object file (E.g. for @.str in your example) will lead to failures.
>>>>>>
>>>>>> I would recommend trying MCJIT with the current development branch of
>>>>>> LLVM - you will probably have more luck there.
>>>>>>
>>>>>> Don't hesitate to file bugs for any issues you run in to on the
>>>>>> development branch - the more test cases we have the easier it will be to
>>>>>> get MachO/ARM fully supported in MCJIT.
>>>>>>
>>>>>> Regards,
>>>>>> Lang.
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 17, 2014 at 12:11 PM, Anton Smirnov <
>>>>>> dev at antonsmirnov.name> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/265d8383/attachment.html>
More information about the llvm-dev
mailing list