[cfe-dev] exc_bad_instruction on arm

Anton Smirnov dev at antonsmirnov.name
Thu Sep 18 11:14:14 PDT 2014


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/5b826475/attachment.html>


More information about the cfe-dev mailing list