exc_bad_instruction on arm

hi.

i’m trying to compile (seems to be sucessfully) and execute code on arm (ios apple ipad air) and i’m having exc_bad_instruction (code=exc_arm_undefined, subcode=0x8458b00) exception.

source code:

int main(int count, const char **args) {
const char *c = “hello world”;
return 1 + 5;
}

generate bit-code cmd:

const char *cmd = {
“clang”,
“-cc1”,
“-triple”,
“arm-apple-macosx10.10.0”, //“thumbv7-apple-ios7.1.0”, //“arm-apple-macosx10.10.0”, // “i386-apple-macosx10.10.0”,
“-emit-llvm”,
“-disable-free”,
“-main-file-name”,
[cppShortFile UTF8String],
“-mrelocation-model”,
“pic”,
“-pic-level”,
“2”,
“-mdisable-fp-elim”,
“-masm-verbose”,
“-target-cpu”,
“cortex-a8”, //“yonah”,
“-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”,
//“-I”,
// [[[[ASPathHolder sharedHolder] includeFolder] stringByAppendingString:@“/libc”] UTF8String], // libc include folder
//“-I”,
// [[[[ASPathHolder sharedHolder] includeFolder] stringByAppendingString:@“/libcxx”] UTF8String], // libc++ include folder
“-stack-protector”,
“1”,
“-mstackrealign”,
//“-fblocks”, // Apple “blocks” extensions
//“-fobjc-runtime=macosx-fragile-10.10.0”, // object-c runtime
//“-fobjc-subscripting-legacy-runtime”,
“-fencode-extended-block-signature”,
“-fcxx-exceptions”,
“-fexceptions”,
“-fdiagnostics-show-option”,
“-vectorize-slp”,
“-target-feature”,
“+soft-float-abi”,
“-target-abi”,
“apcs-gnu”,
“-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”
};

i’m not sure i’m using correct triple, target cpu and target features but i used xcodes ones (when targeting ios device).

compilation was successfull and i’m having .ll file:

; ModuleID = ‘/var/mobile/Applications/53D60D11-DF93-4129-AD97-B96424D165B5/Documents/projects/calc/calc.cpp’
target datalayout = “e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:32:64-v128:32:128-a0:0:32-n32-S32”
target triple = “thumbv7-apple-ios7.1.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 4
%c = alloca i8*, align 4
store i32 0, i32* %retval
store i32 %count, i32* %count.addr, align 4
store i8** %args, i8*** %args.addr, align 4
store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8** %c, align 4
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.4 (tags/RELEASE_34/final 212412)”}

is it correct or can you see obvious errors?

then i’m trying to interpret .ll file.
i’ve copied lli tool source code and launching it from my ios app (created static lib instead of executable) with default arguments (like triple and cpu and so on - this can probably be wrong!).

Then i’m having exception in ExecutionEngine.cpp in line:

return runFunction(Fn, GVArgs).IntVal.getZExtValue();

exc_bad_instruction (code=exc_arm_undefined, subcode=0x8458b00)

Any thoughts? What does this subcode mean?

Any help is highly appreciated.

Regards, Anton.

correction: triple for compilation was “thumbv7-apple-ios7.1.0” - see compiled .ll code

i’ve changed lli arguments to the next (instead of default):

return llvm_interpret(
InputFile,
std::vectorstd::string(),
false, // ForceInterpreter
false, // UseMCJIT
false, // DebugIR
false, // RemoteMCJIT
“”, // MCJITRemoteProcess
’ ', // OptLevel
std::string(“thumbv7-apple-ios7.1.0”), // TargetTriple
std::string(“thumb”), // MArch
std::string(“cortex-a8”), // MCPU
std::vectorstd::string(), // MAttrs
“main”, // EntryFunc
std::vectorstd::string(), // ExtraModules
std::string(), // FakeArgv0
false, // DisableCoreFiles
false, // NoLazyCompilation
Reloc::PIC_, // RelocModel
CodeModel::JITDefault, // CMModel
true, // GenerateSoftFloatCalls
FloatABI::Soft, // FloatABIForCalls
false, // EmitJitDebugInfo
false, // EmitJitDebugInfoToDisk
envp // envp
);

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!
0 iCode 0x01f7e591 llvm::sys::PrintStackTrace(__sFILE*) + 44
1 iCode 0x01f7e807 PrintStackTraceSignalHandler(void*) + 26
2 iCode 0x01f7eb09 SignalHandler(int) + 356
3 libsystem_platform.dylib 0x397e171b _sigtramp + 34
4 libsystem_pthread.dylib 0x397e67b7 pthread_kill + 58
5 iCode 0x01f7e81f raise + 18
6 iCode 0x01f7e8b5 abort + 16
7 iCode 0x01f6d395 llvm::SmallVector<char, 64u>::SmallVector() + 0
8 iCode 0x01410bd5 (anonymous namespace)::ARMCodeEmitter::emitInstruction(llvm::MachineInstr const&) + 1652
9 iCode 0x01410521 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction(llvm::MachineFunction&) + 556
10 iCode 0x016788f5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 72
11 iCode 0x018749ad llvm::FPPassManager::runOnFunction(llvm::Function&) + 252
12 iCode 0x018744ab llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 78
13 iCode 0x01874455 llvm::legacy::FunctionPassManager::run(llvm::Function&) + 200
14 iCode 0x01a36d9d llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 44
15 iCode 0x01a36c31 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 112
16 iCode 0x01a36f7f llvm::JIT::getPointerToFunction(llvm::Function*) + 450
17 iCode 0x000da28d llvm_interpret(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, char, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, bool, bool, llvm::Reloc::Model, llvm::CodeModel::Model, bool, llvm::FloatABI::ABIType, bool, bool, char*) + 4364
18 iCode 0x000db8c7 llvm_interpret(char const*, char*) + 1346
19 iCode 0x000dbb83 llvm_interpret(char const*, char*, char const*) + 134
20 iCode 0x000b0973 -[ASMainController didClickCompile:] + 2446
21 UIKit 0x30f656a7 + 90
22 UIKit 0x310cc56d + 120
23 UIKit 0x30f656a7 + 90
24 UIKit 0x30f65643 + 38
25 UIKit 0x30f65613 + 46
26 UIKit 0x30f50d5b + 374
27 UIKit 0x30f6505b + 594
28 UIKit 0x30f28521 + 5528
29 CoreFoundation 0x2e6c9ff9 + 20
30 CoreFoundation 0x2e6c7987 + 286
31 CoreFoundation 0x2e6c7cd3 + 738
32 CoreFoundation 0x2e632729 CFRunLoopRunSpecific + 524
33 CoreFoundation 0x2e63250b CFRunLoopRunInMode + 106
34 GraphicsServices 0x3355e6d3 GSEventRunModal + 138
35 UIKit 0x30f93871 UIApplicationMain + 1136
36 iCode 0x000d0829 main + 116
37 libdyld.dylib 0x396c7ab7 + 2
Stack dump:
0. Running pass ‘ARM Machine Code Emitter’ on function ‘@main
0 iCode 0x01f7e591 llvm::sys::PrintStackTrace(__sFILE*) + 44
1 iCode 0x01f7e807 PrintStackTraceSignalHandler(void*) + 26
2 iCode 0x01f7eb09 SignalHandler(int) + 356
3 libsystem_platform.dylib 0x397e171b _sigtramp + 34
4 libsystem_pthread.dylib 0x397e67b7 pthread_kill + 58
5 iCode 0x01f7e81f raise + 18
6 iCode 0x01f7e8b5 abort + 16
7 iCode 0x01f6d395 llvm::SmallVector<char, 64u>::SmallVector() + 0
8 iCode 0x01410bd5 (anonymous namespace)::ARMCodeEmitter::emitInstruction(llvm::MachineInstr const&) + 1652
9 iCode 0x01410521 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction(llvm::MachineFunction&) + 556
10 iCode 0x016788f5 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 72
11 iCode 0x018749ad llvm::FPPassManager::runOnFunction(llvm::Function&) + 252
12 iCode 0x018744ab llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 78
13 iCode 0x01874455 llvm::legacy::FunctionPassManager::run(llvm::Function&) + 200
14 iCode 0x01a36d9d llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 44
15 iCode 0x01a36c31 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 112
16 iCode 0x01a36f7f llvm::JIT::getPointerToFunction(llvm::Function*) + 450
17 iCode 0x000da28d llvm_interpret(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, bool, bool, bool, bool, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, char, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, bool, bool, llvm::Reloc::Model, llvm::CodeModel::Model, bool, llvm::FloatABI::ABIType, bool, bool, char*) + 4364
18 iCode 0x000db8c7 llvm_interpret(char const*, char*) + 1346
19 iCode 0x000dbb83 llvm_interpret(char const*, char*, char const*) + 134

this seems to be different arguments between compile and interpret or bitcode was generated incorrectly?

Hi Anton,

I've added the llvmdev list, since the issues you're seeing are coming
from the backend, which is more their side.

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.

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.

Both Clang/LLVM 3.4 → Clang/LLVM 3.5

And i will also try using MCJIT.

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::vectorstd::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::vectorstd::string(), // MAttrs
“main”, // EntryFunc
std::vectorstd::string(), // ExtraModules
std::vectorstd::string(), // ExtraObjects
std::vectorstd::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.

I’ve also tried the next combination:

true, // ForceInterpreter
false, // UseMCJIT

and ios app just crashed with no output

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.

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.

Hi Anton,

I don’t follow what you’re asking?

For (1): You can compile c++ files to .ll files with clang - it seems like you’ve already worked that out.

For (2): What do you mean “supported at the moment”? In the 3.5 release MCJIT is known to be broken for MachO/ARM. The Interpreter and the JIT are both poorly tested (and seem to be broken, as you discovered). On the development branch many of the bugs in MCJIT have been fixed, and I would expect MCJIT to work for simple test cases. The JIT has been removed entirely, and the Interpreter is still poorly tested. :slight_smile:

I look forward to checking out the bug reports.

Good luck!

  • Lang.

Hi, Lang.

Hi Anton,

I don't follow what you're asking?

For (1): You can compile c++ files to .ll files with clang - it seems like
you've already worked that out.

For (2): What do you mean "supported at the moment"? In the 3.5 release
MCJIT is known to be broken for MachO/ARM. The Interpreter and the JIT are
both poorly tested (and seem to be broken, as you discovered). On the
development branch many of the bugs in MCJIT have been fixed, and I would
expect MCJIT to work for simple test cases. The JIT has been removed
entirely, and the Interpreter is still poorly tested. :slight_smile:

You understood correctly what i was asking for.

I look forward to checking out the bug reports.

Sure, just let me remove unneeded source code from my ios app and clean-up
my build scripts for lli static lib.

Good luck!

Regards, Anton.

Hi, all.

I’ve cloned llvm/clang trunk sources, configured with the same arguments (as for llvm 3.5 release):

–host=i386-apple-darwin11 --enable-threads=no --disable-threads --disable-terminfo --enable-languages=c,c++ --enable-zlib=no --disable-zlib --enable-targets=x86_64,arm,arm64

After that i recompiled my interpreter lib (remember it’s almost lli) with code changed (i was surprised how it’s changed since 3.5 release!)

and created ios app that uses lib to test arm64 interpret issue. Then i was surprised to get the next output:

libInterpreter: error creating EE: No available targets are compatible with this triple, see -version for the available targets.

.ll file i’m trying to execute/interpret is almost as previous one (i’ve added some code to it), but triple is the same:

; ModuleID = ‘./test.cpp’

target datalayout = “e-m:o-i64:64-i128:128-n32:64-S128”

target triple = “arm64-apple-ios7.0.0”

@.str = private unnamed_addr constant [12 x i8] c"hello world\00", align 1

; Function Attrs: nounwind ssp

define i32 @main(i32 %argc, i8** %argv) #0 {

entry:

%retval = alloca i32, align 4

%argc.addr = alloca i32, align 4

%argv.addr = alloca i8**, align 8

%c = alloca i8*, align 8

%a = alloca i32, align 4

%b = alloca i32, align 4

store i32 0, i32* %retval

store i32 %argc, i32* %argc.addr, align 4

store i8** %argv, i8*** %argv.addr, align 8

store i8* getelementptr inbounds ([12 x i8]* @.str, i32 0, i32 0), i8** %c, align 8

store i32 1, i32* %a, align 4

%0 = load i32* %a, align 4

%add = add nsw i32 %0, 6

store i32 %add, i32* %b, align 4

ret i32 3

}

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.6.0 (trunk 218116) (llvm/trunk 218115)”}

I’ve compiled llvm_trunk (same source for host and compiled it using -emit-llvm -S -c … -o -target arm64-apple-ios7.0) so this target is supported.
so i can’t understand why i’m getting such error on the same code but on arm (instead of my x86_64).

What should i do?

Regards, Anton.

i’ve found why it was unavailable to find target - changed InitializeNative* to InitializeAll* methods (see lli source code).

Anyway now i’m just getting exception as i wrote before.
I’ve posted bug report (http://llvm.org/bugs/show_bug.cgi?id=21012) with:

  1. full issue description
  2. static library sources
  3. lib build script
  4. ios app that uses lib and where you can reproduce exception

i hope my efforts will be awarded and someone fix it.
also i will do my best in order to fix it ASAP.

please contact me on email or skype (anton.smirnov.skype) to get more information if needed.

Cheers,
Anton.

any update on this?