[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