On 2014-01-05 18:28, Dan Olson wrote:

> Hi Jacob.
>
> Yeah, I probably have called it wrong as I am just learning about
> exception handling implementations.  clangc c++ exception handling for
> C++ armv7-apple-darwin is emitting __gxx_personality_sj0 and plugs in
> _Unwind_SjLj_Register/_Unwind_SjLj_Unregister.  Perhaps those are just
> for catching C code longjmps?

I had a look the code for libc++abi. It seems that on ARM it uses SjLj but with the same API as dwarf based exceptions, that is __cxa_begin_catch, __cxa_end_catch and so on. I didn't expect that.

-- 
/Jacob Carlborg

"Kai Nacke" <kai@redstar.de> writes:

> Hi Dan!
>
> I think using trunk is always the best option if you port ldc to a new platform. I try to keep ldc in sync with LLVM trunk therefore you should have no problems with using trunk.
>
> If the bug is also present in trunk then you should enter a bug report at http://llvm.org/bugs. It sounds pretty bad.
>
> Could you please post which triple you are suing and on which druntime files you get assertion errors? An assertion in LLVM may also be triggered by bad IR. I like to have a look at it.
>
> Regards,
> Kai

Hi Kai,

I updated to llvm trunk and ldc git HEAD.  Again, I am working on OSX Lion.

I built llvm with:
$ CC=/opt/local/bin/gcc-mp-4.8 CXX=/opt/local/bin/c++-mp-4.8 ../llvm-svn/configure --target=armv7-apple-darwin
$ make

I am building ldc with something like:
CC=/opt/local/bin/gcc-mp-4.8 CXX=/opt/local/bin/c++-mp-4.8 cmake -DLLVM_ROOT_DIR=/Users/dan/projects/ldc/build-svn/Debug+Asserts/ -DD_FLAGS='-w;-d;-mtriple=armv7-apple-darwin' ../ldc-git

Earlier I hacked around around TLS and eh/threading in druntime but have not applied those changes to ldc-git.  So you can ignore theTLS assertion and some D compile errors, if you get that far.

I am seeing many assertions and segvs.  The four triples I am working with are: armv7-apple-darwin, thumbv7-, armv6-, and thumbv6-.

** thumbv6-apple-darwin causes no assertion problems, it just generates the funky eh function prolog I reported earlier:

  push {d8, d9, d10, d11, d12, d13, d14, d15, r8, r10, r11,r4, r5, r6, r7, lr}
  pop {d8, d9, d10, d11, d12, d13, d14, d15, r8, r10, r11,r4, r5, r6, r7, pc}

Both armv7-apple-darwin and armv6-apple-darwin result in segv on many files.

Examples:
** armv7-apple-darwin
src/core/demangle.o is first, but many files
0  ldc2              0x00000001078fa585 llvm::sys::PrintStackTrace(__sFILE*) + 38
1  ldc2              0x00000001078fa802 PrintStackTraceSignalHandler(void*) + 30
2  ldc2              0x00000001078fa264 SignalHandler(int) + 268
3  libsystem_c.dylib 0x00007fff87bbf90a _sigtramp + 26
4  libsystem_c.dylib 0x00007fe60208ab10 _sigtramp + 2051846688
5  ldc2              0x0000000106ac8374 llvm::ARMAsmPrinter::EmitInstruction(llvm::MachineInstr const*) + 274
6  ldc2              0x000000010709dfce llvm::AsmPrinter::EmitFunctionBody() + 1418
7  ldc2              0x0000000106acc977 llvm::AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 59
8  ldc2              0x0000000106ac1ea5 llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 81
9  ldc2              0x00000001071ccc53 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
10 ldc2              0x000000010775fd84 llvm::FPPassManager::runOnFunction(llvm::Function&) + 290
11 ldc2              0x000000010775fb2a llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 84
12 ldc2              0x000000010775f70a llvm::legacy::FunctionPassManager::run(llvm::Function&) + 180
13 ldc2              0x00000001064dcb31 codegenModule(llvm::TargetMachine&, llvm::Module&, llvm::raw_fd_ostream&, llvm::TargetMachine::CodeGenFileType) + 473
14 ldc2              0x00000001064dd6f8 writeModule(llvm::Module*, std::string) + 1851
15 ldc2              0x00000001064e6175 main + 5362
16 libdyld.dylib     0x00007fff91a6c7e1 start + 0
17 libdyld.dylib     0x000000000000000d start + 1851340844
/bin/sh: line 1: 59338 Segmentation fault: 11  /Users/dan/projects/ldc/buildldc-svn/bin/ldc2 --output-o -c -I/Users/dan/projects/ldc/ldc-git/runtime/druntime/src -I/Users/dan/projects/ldc/ldc-git/runtime/druntime/src/gc /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/core/demangle.d -of/Users/dan/projects/ldc/buildldc-svn/runtime/src/core/demangle.o -w -d -mtriple=armv7-apple-darwin -O3 -release -disable-invariants

** armv6-apple-darwin
src/core/cpuid.o is first
0  ldc2              0x0000000103110585 llvm::sys::PrintStackTrace(__sFILE*) + 38
1  ldc2              0x0000000103110802 PrintStackTraceSignalHandler(void*) + 30
2  ldc2              0x0000000103110264 SignalHandler(int) + 268
3  libsystem_c.dylib 0x00007fff87bbf90a _sigtramp + 26
4  libsystem_c.dylib 0x00007fbd32051a10 _sigtramp + 2856919328
5  ldc2              0x00000001022de374 llvm::ARMAsmPrinter::EmitInstruction(llvm::MachineInstr const*) + 274
6  ldc2              0x00000001028b3fce llvm::AsmPrinter::EmitFunctionBody() + 1418
7  ldc2              0x00000001022e2977 llvm::AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 59
8  ldc2              0x00000001022d7ea5 llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 81
9  ldc2              0x00000001029e2c53 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
10 ldc2              0x0000000102f75d84 llvm::FPPassManager::runOnFunction(llvm::Function&) + 290
11 ldc2              0x0000000102f75b2a llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 84
12 ldc2              0x0000000102f7570a llvm::legacy::FunctionPassManager::run(llvm::Function&) + 180
13 ldc2              0x0000000101cf2b31 codegenModule(llvm::TargetMachine&, llvm::Module&, llvm::raw_fd_ostream&, llvm::TargetMachine::CodeGenFileType) + 473
14 ldc2              0x0000000101cf36f8 writeModule(llvm::Module*, std::string) + 1851
15 ldc2              0x0000000101cfc175 main + 5362
16 libdyld.dylib     0x00007fff91a6c7e1 start + 0
/bin/sh: line 1: 61457 Segmentation fault: 11  /Users/dan/projects/ldc/buildldc-svn/bin/ldc2 --output-o -c -I/Users/dan/projects/ldc/ldc-git/runtime/druntime/src -I/Users/dan/projects/ldc/ldc-git/runtime/druntime/src/gc /Users/dan/projects/ldc/ldc-git/runtime/druntime/src/core/cpuid.d -of/Users/dan/projects/ldc/buildldc-svn/runtime/src/core/cpuid.o -w -d -mtriple=armv6-apple-darwin -O3 -release -disable-invariants

** thumbv7-apple-darwin
No segvs but various assertion failures.

Files src/core/demangle.o src/core/runtime.o src/rt/cover.o src/rt/util/utf.o

Assertion failed: ((TLI.getTypeAction(*DAG.getContext(), Node->getOperand(i).getValueType()) == TargetLowering::TypeLegal || Node->getOperand(i).getOpcode() == ISD::TargetConstant) && "Unexpected illegal type!"), function LegalizeOp, file /Users/dan/projects/ldc/llvm-svn/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 1165.

Files: src/core/sync/rwmutex.o src/gc/gc.o src/core/sync/config-debug.o src/core/sync/rwmutex-debug.o src/gc/gcx-debug.o src/rt/minfo-debug.o src/rt/tlsgc-debug.o

Assertion failed: (MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!"), function getLoad, file /Users/dan/projects/ldc/llvm-svn/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 4543.

Files: src/core/sys/posix/sys/select.o src/object_.o src/gc/gcx.o src/rt/aaA.o src/rt/adi.o src/rt/sections_ldc.o src/rt/cover-debug.o

SoftenFloatOperand Op #0: 0x7fa1f2050710: v2f64 = BUILD_VECTOR 0x7fa1f2052910, 0x7fa1f2052910 [ID=0]

Do not know how to soften this operator's operand!
UNREACHABLE executed at /Users/dan/projects/ldc/llvm-svn/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp:622!

-- 
Dan

Hi Dan!

On Tuesday, 21 January 2014 at 09:09:37 UTC, Dan Olson wrote:
> [...]
> I am seeing many assertions and segvs.  The four triples I am working
> with are: armv7-apple-darwin, thumbv7-, armv6-, and thumbv6-.
> [...]

Thanks for the examples. I'll have a look at it this evening. Maybe I can create reduced test cases.

Regards,
Kai

On Tuesday, 21 January 2014 at 11:50:59 UTC, Kai Nacke wrote:
> Hi Dan!
>
> On Tuesday, 21 January 2014 at 09:09:37 UTC, Dan Olson wrote:
>> [...]
>> I am seeing many assertions and segvs.  The four triples I am working
>> with are: armv7-apple-darwin, thumbv7-, armv6-, and thumbv6-.
>> [...]
>
> Thanks for the examples. I'll have a look at it this evening. Maybe I can create reduced test cases.
>
> Regards,
> Kai

This code

import ldc.intrinsics;

real cos(real x) @safe pure nothrow { return llvm_cos(x); }

crashes ldc if compiled with -c -mtriple=armv7-apple-darwin.

Regards,
Kai

On Tuesday, 21 January 2014 at 19:02:56 UTC, Kai Nacke wrote:
> This code
>
> import ldc.intrinsics;
>
> real cos(real x) @safe pure nothrow { return llvm_cos(x); }
>
> crashes ldc if compiled with -c -mtriple=armv7-apple-darwin.

My first impression was that it has something to do with the real data type. But it turns out to be a problem with writing the object file.

There seems to be no problem if you specify -output-s or -output-ll, too.

Regards,
Kai

On Wednesday, 22 January 2014 at 06:15:11 UTC, Kai Nacke wrote:
> On Tuesday, 21 January 2014 at 19:02:56 UTC, Kai Nacke wrote:
>> This code
>>
>> import ldc.intrinsics;
>>
>> real cos(real x) @safe pure nothrow { return llvm_cos(x); }
>>
>> crashes ldc if compiled with -c -mtriple=armv7-apple-darwin.
>
> My first impression was that it has something to do with the real data type. But it turns out to be a problem with writing the object file.
>
> There seems to be no problem if you specify -output-s or -output-ll, too.
>
> Regards,
> Kai

Slightly OT but I am just really curious: how long do you think it will take to make D work on iOS? 3 months? 6? By the end of the year? Asking because it is a major argument when convincing my managers to switch from C++. I am sooo rooting for you guys!

"Szymon Gatner" <noemail@gmail.com> writes:
>
> Slightly OT but I am just really curious: how long do you think it will take to make D work on iOS? 3 months? 6? By the end of the year? Asking because it is a major argument when convincing my managers to switch from C++. I am sooo rooting for you guys!

Hi Szymon,

I don't know if anybody else is working on it and for me it is just a hobby/fun puzzle to use D in iOS.  I do not write iOS apps for a living and am not sure where Apple would stand on getting a D-based app through the App Store review.  It is too early to consider D as a viable iOS compiler chain.

Right now we are stuck on proper code gen.  Then there will be implementation of proper thread support, exception handling, thread local vars, and passing the D runtime/phobos unittests.  And much more.

-- 
Dan

On 2014-01-23 06:34, Dan Olson wrote:

> Hi Szymon,
>
> I don't know if anybody else is working on it and for me it is just a
> hobby/fun puzzle to use D in iOS.  I do not write iOS apps for a living
> and am not sure where Apple would stand on getting a D-based app through
> the App Store review.  It is too early to consider D as a viable iOS
> compiler chain.

I don't know why the wouldn't accept D since they accept applications built with C# and similar.

-- 
/Jacob Carlborg

On 2014-01-22 17:40, Szymon Gatner wrote:

> Slightly OT but I am just really curious: how long do you think it will
> take to make D work on iOS? 3 months? 6? By the end of the year? Asking
> because it is a major argument when convincing my managers to switch
> from C++. I am sooo rooting for you guys!

If you don't want to use the Objective-C runtime API to interface with the Objective-C frameworks you need D to be ABI compatible with Objective-C as well, something like this:


http://michelf.ca/projects/d-objc/syntax/
https://github.com/jacob-carlborg/dmd/tree/d-objc

-- 
/Jacob Carlborg

On Thursday, 23 January 2014 at 08:02:39 UTC, Jacob Carlborg wrote:
> On 2014-01-23 06:34, Dan Olson wrote:
>
>> Hi Szymon,
>>
>> I don't know if anybody else is working on it and for me it is just a
>> hobby/fun puzzle to use D in iOS.  I do not write iOS apps for a living
>> and am not sure where Apple would stand on getting a D-based app through
>> the App Store review.  It is too early to consider D as a viable iOS
>> compiler chain.

Thanks, for info. Sounds like a lot of work :( Thanks for doing this!

>
> I don't know why the wouldn't accept D since they accept applications built with C# and similar.

Exactly, I think there should be no problem here either. They accept C#, Lua... only JITting is forbidden.