[cfe-dev] exc_bad_instruction on arm
Anton Smirnov
dev at antonsmirnov.name
Thu Sep 18 11:46:59 PDT 2014
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/cfe-dev/attachments/20140919/b0767dc5/attachment.html>
More information about the cfe-dev
mailing list