[LLVMdev] [cfe-dev] exc_bad_instruction on arm

Lang Hames lhames at gmail.com
Thu Sep 18 10:00:05 PDT 2014


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/20140918/363ac69b/attachment.html>


More information about the llvm-dev mailing list