[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