[cfe-dev] exc_bad_instruction on arm

Anton Smirnov dev at antonsmirnov.name
Wed Sep 17 11:47:57 PDT 2014


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.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140918/5002f02f/attachment.html>


More information about the cfe-dev mailing list