[LLVMdev] [cfe-dev] exc_bad_instruction on arm

Anton Smirnov dev at antonsmirnov.name
Sat Sep 20 10:44:04 PDT 2014


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/20140920/8fd91ae2/attachment.html>


More information about the llvm-dev mailing list