Jump to page: 1 27  
Page
Thread overview
iphone + LDC, a new ARM adventure
Jan 04, 2014
Dan Olson
Jan 04, 2014
David Nadlinger
Jan 05, 2014
Dan Olson
Jan 05, 2014
Jacob Carlborg
Jan 05, 2014
Dan Olson
Jan 06, 2014
Jacob Carlborg
Jan 06, 2014
Dan Olson
Jan 06, 2014
David Nadlinger
Jan 06, 2014
Dan Olson
Jan 08, 2014
Dan Olson
Jan 09, 2014
Kai Nacke
Jan 09, 2014
Dan Olson
Jan 09, 2014
Kai Nacke
Jan 10, 2014
Dan Olson
Jan 10, 2014
Dan Olson
Jan 10, 2014
David Nadlinger
Jan 12, 2014
Dan Olson
Jan 15, 2014
Dan Olson
Jan 16, 2014
Dan Olson
Jan 19, 2014
Dan Olson
Jan 20, 2014
Kai Nacke
Jan 21, 2014
Dan Olson
Jan 21, 2014
Kai Nacke
Jan 21, 2014
Kai Nacke
Jan 22, 2014
Kai Nacke
Jan 22, 2014
Szymon Gatner
Jan 23, 2014
Dan Olson
Jan 23, 2014
Jacob Carlborg
Jan 23, 2014
Szymon Gatner
Jan 23, 2014
Dan Olson
Jan 23, 2014
Jacob Carlborg
Jan 23, 2014
Jacob Carlborg
Jan 30, 2014
Dan Olson
Jan 31, 2014
Jacob Carlborg
Jan 31, 2014
Dan Olson
Feb 05, 2014
Dan Olson
Feb 05, 2014
Szymon Gatner
Feb 05, 2014
Dan Olson
Feb 05, 2014
Kai Nacke
Feb 05, 2014
Dan Olson
Feb 05, 2014
Jacob Carlborg
Feb 06, 2014
Joakim
Feb 09, 2014
Dan Olson
Feb 10, 2014
Dan Olson
Feb 12, 2014
David Nadlinger
Feb 12, 2014
Dan Olson
Feb 05, 2014
Jacob Carlborg
Feb 05, 2014
Dan Olson
Feb 05, 2014
Xavier Bigand
Feb 10, 2014
David Nadlinger
Feb 01, 2014
Kai Nacke
Feb 01, 2014
Dan Olson
Feb 02, 2014
Dan Olson
Feb 03, 2014
Kai Nacke
Jan 09, 2014
David Nadlinger
Jan 10, 2014
Dan Olson
Jan 06, 2014
Jacob Carlborg
Jan 06, 2014
David Nadlinger
Jan 06, 2014
David Nadlinger
Jan 06, 2014
Kai Nacke
Jan 06, 2014
David Nadlinger
Jan 06, 2014
Dan Olson
Jan 20, 2014
Jacob Carlborg
Jan 06, 2014
Kai Nacke
January 04, 2014
Compiling LDC for iphone ARM. Running into expected problems, but thought I'd post status so I am not working in a vacuum. I am new to building LLVM as of this week so more likely to miss configuration options.

During the LDC build, druntime and phobos run into a few problems (3 types of error), which don't suprise me because I don't think many have tried this combo yet (arm-apple-darwin). However, I can compile a simple standalone .d file to .o and link it into an xcode iphone arm project and run it on hardware.

First class of error I run into is exception based. Any code that needs to handle exceptions gets this:

Assertion failed: (getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file /Users/dan/projects/ldc/llvm-3.3.src/lib/IR/Instructions.cpp, line 1084.
... snip
0.	Running pass 'SJLJ Exception Handling preparation' on function '@_D4core8demangle8Demangle9parseTypeMFAaZAa'
/bin/sh: line 1: 53946 Illegal instruction: 4  /Users/dan/projects/ldc/buildldc-3.3-hacked-armv7/bin/ldc2 --output-o -c -I/Users/dan/projects/ldc/ldc-0.12.1-src/runtime/druntime/src -I/Users/dan/projects/ldc/ldc-0.12.1-src/runtime/druntime/src/gc /Users/dan/projects/ldc/ldc-0.12.1-src/runtime/druntime/src/core/demangle.d -of/Users/dan/projects/ldc/buildldc-3.3-hacked-armv7/runtime/src/core/demangle.o -w -d -march=thumb -relocation-model=static -O3 -release -disable-invariants

Any thoughts?

Dan

----

Build machine is Lion using clang x86_64-apple-darwin12.5.0

I tried various LLVM --target configurations (arm, armv7, x86-apple-darwin), but they do not seem to make a difference in the resulting ldc2. LLVM 3.3 yields fewer errors when build druntime than 3.2.  Both give me the same exception error above.

I am using -march=thumb -relocation-model=static as I seem to encounter fewer llvm failures with these flags. I updated ldc-0.12.1-src/runtime/CMakeLists.txt and changed D_FLAGS to include these.

The compiler reports this:

/Users/dan/projects/ldc/buildldc-3.3-hacked-armv7/bin/ldmd2 -help
LDC - the LLVM D compiler (0.12.0):
  based on DMD v2.063.2 and LLVM 3.3
  Default target: armv7-apple-darwin12.5.0
  Host CPU: corei7-avx
  http://dlang.org - http://wiki.dlang.org/LDC

  Registered Targets:
    aarch64  - AArch64
    arm      - ARM
    cpp      - C++ backend
    hexagon  - Hexagon
    mblaze   - MBlaze
    mips     - Mips
    mips64   - Mips64 [experimental]
    mips64el - Mips64el [experimental]
    mipsel   - Mipsel
    msp430   - MSP430 [experimental]
    nvptx    - NVIDIA PTX 32-bit
    nvptx64  - NVIDIA PTX 64-bit
    ppc32    - PowerPC 32
    ppc64    - PowerPC 64
    sparc    - Sparc
    sparcv9  - Sparc V9
    systemz  - SystemZ
    thumb    - Thumb
    x86      - 32-bit X86: Pentium-Pro and above
    x86-64   - 64-bit X86: EM64T and AMD64
    xcore    - XCore


Background:

About a year ago, I worked and gave up on making gdc build druntime and phobos for iphone (ios arm). I could get a simple standalone D function to run on an iphone but no further.

http://www.digitalmars.com/d/archives/D/gnu/iphone_D_getting_closer_4788.html

The problem was that gcc-4.8 had no support for iphone and the latest sources that apple released were for gcc-4.2. I tried in vain to merge the iphone changes into 4.8, but it was a losing battle.

I have always wanted to continue this adventure, trying LDC. Apple is all clang/LLVM now and seems to be pushing out some of their LLVM updates.  So seems LDC is way to go!
January 04, 2014
Hi Dan,

On Sat, Jan 4, 2014 at 10:56 PM, Dan Olson <zans.is.for.cans@yahoo.com> wrote:
> First class of error I run into is exception based. Any code that needs to handle exceptions gets this:
>
> Assertion failed: (getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"), function AssertOK, file /Users/dan/projects/ldc/llvm-3.3.src/lib/IR/Instructions.cpp, line 1084.

The issue is most likely that ARM/iOS uses setjmp/longjmp-based exception handling, whereas all the other target platforms use DWARF-based EH (or a similar concept on Win64).

I don't see any fundamental issue with using SLJL for D/LDC (besides performance and the other generic SLJL downsides), but you'd have to adapt druntime and also some parts of the relevant parts of the LDC glue code (e.g. to avoid the above error).

> I have always wanted to continue this adventure, trying LDC. Apple is all clang/LLVM now and seems to be pushing out some of their LLVM updates.  So seems LDC is way to go!

If you have the time and inclination to work on iOS support for ARM, it would be awesome if you could try to get things running. In any case, please do feel free to ask around for help with LDC development.

Best,
David
January 05, 2014
David Nadlinger <code@klickverbot.at> writes:

> The issue is most likely that ARM/iOS uses setjmp/longjmp-based exception handling, whereas all the other target platforms use DWARF-based EH (or a similar concept on Win64).
>
> I don't see any fundamental issue with using SLJL for D/LDC (besides performance and the other generic SLJL downsides), but you'd have to adapt druntime and also some parts of the relevant parts of the LDC glue code (e.g. to avoid the above error).

Thanks David for the reply.

Ah, I didn't connect SLJL with setjmp/longjmp. Good clue. Yes, it appears arm-apple-darwin exceptions are setjmp based (confirmed by compiling a c++ function with clang). Ok, I will dig in some more, see where it leads me.

>> I have always wanted to continue this adventure, trying LDC. Apple is all clang/LLVM now and seems to be pushing out some of their LLVM updates.  So seems LDC is way to go!
>
> If you have the time and inclination to work on iOS support for ARM, it would be awesome if you could try to get things running. In any case, please do feel free to ask around for help with LDC development.
>
> Best,
> David

Yes, just a hobby, but would very much like to make D on ios. So far, llvm looks easier to understand than gcc codebase, and toolchain builds are much faster. Better for trial and error.
January 05, 2014
On 2014-01-05 08:34, Dan Olson wrote:

> Ah, I didn't connect SLJL with setjmp/longjmp. Good clue. Yes, it
> appears arm-apple-darwin exceptions are setjmp based (confirmed by
> compiling a c++ function with clang). Ok, I will dig in some more, see
> where it leads me.

Hmm, I would have thought iOS used DWARF-based exception handling.

-- 
/Jacob Carlborg
January 05, 2014
Jacob Carlborg <doob@me.com> writes:

> On 2014-01-05 08:34, Dan Olson wrote:
>
>> Ah, I didn't connect SLJL with setjmp/longjmp. Good clue. Yes, it appears arm-apple-darwin exceptions are setjmp based (confirmed by compiling a c++ function with clang). Ok, I will dig in some more, see where it leads me.
>
> Hmm, I would have thought iOS used DWARF-based exception handling.

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?

For example, this C++ code:

    try {
        death();
    }
    catch (...) {
        puts("got it");
    }

produced (edited):

_main:
	.cfi_startproc
	.cfi_personality 155, L___gxx_personality_sj0$non_lazy_ptr
Leh_func_begin0:
	.cfi_lsda 16, Lexception0
@ BB#0:                                 @ %entry
	push	{r4, r5, r6, r7, lr}

--- snip ---

LPC0_1:
	add	r1, pc
	str.w	sp, [sp, #52]
	str	r1, [sp, #48]
	movs	r1, #1
	str	r1, [sp, #16]
	blx	__Unwind_SjLj_Register
Ltmp0:
	blx	__Z5deathv
Ltmp1:
LBB0_1:                                 @ %try.cont
	add	r0, sp, #12
	blx	__Unwind_SjLj_Unregister
	add	r4, sp, #64
	movs	r0, #0

--- snip function prologue ---

LBB0_5:                                 @ %invoke.cont2
Ltmp2:
	ldr	r0, [sp, #20]
	ldr	r1, [sp, #24]
	blx	___cxa_begin_catch
	movw	r0, :lower16:(L_.str-(LPC0_3+4))
	movt	r0, :upper16:(L_.str-(LPC0_3+4))
LPC0_3:
	add	r0, pc
	blx	_puts
	mov.w	r0, #-1
	str	r0, [sp, #16]
	blx	___cxa_end_catch
	b	LBB0_1

And I do see an exception table.

	.section	__TEXT,__gcc_except_tab
	.align	2
GCC_except_table0:
Lexception0:
L_LSDA_0:
	.byte	255                     @ @LPStart Encoding = omit
	.byte	155                     @ @TType Encoding = indirect pcrel sdata4
	.asciz	 "\212\200\200"         @ @TType base offset
	.byte	3                       @ Call site Encoding = udata4
	.byte	2                       @ Call site table length
	.byte	0                       @ >> Call Site 0 <<
                                        @   On exception at call site 0
	.byte	1                       @   Action: 1
	.byte	1                       @ >> Action Record 1 <<
                                        @   Catch TypeInfo 1
	.byte	0                       @   No further actions
                                        @ >> Catch TypeInfos <<
	.long	0                       @ TypeInfo 1
	.align	2


I read llvm source code for a while yesterday and really haven't wrapped by brain around it yet.

Dan
January 06, 2014
On 2014-01-05 18:28, Dan Olson wrote:
> Jacob Carlborg <doob@me.com> writes:
>
>> On 2014-01-05 08:34, Dan Olson wrote:
>>
>>> Ah, I didn't connect SLJL with setjmp/longjmp. Good clue. Yes, it
>>> appears arm-apple-darwin exceptions are setjmp based (confirmed by
>>> compiling a c++ function with clang). Ok, I will dig in some more, see
>>> where it leads me.
>>
>> Hmm, I would have thought iOS used DWARF-based exception handling.
>
> 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?
>
> For example, this C++ code:
>
>      try {
>          death();
>      }
>      catch (...) {
>          puts("got it");
>      }
>
> produced (edited):
>
> _main:
> 	.cfi_startproc
> 	.cfi_personality 155, L___gxx_personality_sj0$non_lazy_ptr
> Leh_func_begin0:
> 	.cfi_lsda 16, Lexception0
> @ BB#0:                                 @ %entry
> 	push	{r4, r5, r6, r7, lr}
>
> --- snip ---
>
> LPC0_1:
> 	add	r1, pc
> 	str.w	sp, [sp, #52]
> 	str	r1, [sp, #48]
> 	movs	r1, #1
> 	str	r1, [sp, #16]
> 	blx	__Unwind_SjLj_Register
> Ltmp0:
> 	blx	__Z5deathv
> Ltmp1:
> LBB0_1:                                 @ %try.cont
> 	add	r0, sp, #12
> 	blx	__Unwind_SjLj_Unregister
> 	add	r4, sp, #64
> 	movs	r0, #0
>
> --- snip function prologue ---
>
> LBB0_5:                                 @ %invoke.cont2
> Ltmp2:
> 	ldr	r0, [sp, #20]
> 	ldr	r1, [sp, #24]
> 	blx	___cxa_begin_catch
> 	movw	r0, :lower16:(L_.str-(LPC0_3+4))
> 	movt	r0, :upper16:(L_.str-(LPC0_3+4))
> LPC0_3:
> 	add	r0, pc
> 	blx	_puts
> 	mov.w	r0, #-1
> 	str	r0, [sp, #16]
> 	blx	___cxa_end_catch
> 	b	LBB0_1
>
> And I do see an exception table.
>
> 	.section	__TEXT,__gcc_except_tab
> 	.align	2
> GCC_except_table0:
> Lexception0:
> L_LSDA_0:
> 	.byte	255                     @ @LPStart Encoding = omit
> 	.byte	155                     @ @TType Encoding = indirect pcrel sdata4
> 	.asciz	 "\212\200\200"         @ @TType base offset
> 	.byte	3                       @ Call site Encoding = udata4
> 	.byte	2                       @ Call site table length
> 	.byte	0                       @ >> Call Site 0 <<
>                                          @   On exception at call site 0
> 	.byte	1                       @   Action: 1
> 	.byte	1                       @ >> Action Record 1 <<
>                                          @   Catch TypeInfo 1
> 	.byte	0                       @   No further actions
>                                          @ >> Catch TypeInfos <<
> 	.long	0                       @ TypeInfo 1
> 	.align	2
>
>
> I read llvm source code for a while yesterday and really haven't wrapped
> by brain around it yet.

You could try and compare it with x86 64bit code. C++ code on x86 64bit is using DWARF-based exception handling. You can see if that code contains anything related to SLJL.

Also Objective-C on x86 32bit uses SLJL but on 64bit is uses DWARF.

-- 
/Jacob Carlborg
January 06, 2014
On Sunday, 5 January 2014 at 09:36:52 UTC, Jacob Carlborg wrote:
> Hmm, I would have thought iOS used DWARF-based exception handling.

LLVM generates SJLJ exceptions if you use -march=arm -mtriple=arm-darwin.
I know this because there was once an ICE in LDC using the options because of a bug in LLVM. I fixed this in r181802 (http://article.gmane.org/gmane.comp.compilers.llvm.cvs/145269).

Regards,
Kai
January 06, 2014
Hi Dan, Hi Jacob,

On Sun, Jan 5, 2014 at 6:28 PM, Dan Olson <zans.is.for.cans@yahoo.com> wrote:
> Jacob Carlborg <doob@me.com> writes:
>> Hmm, I would have thought iOS used DWARF-based exception handling.
>
> Hi Jacob.
>
> Yeah, I probably have called it wrong as I am just learning about exception handling implementations.

No, even though I'm no expert for iOS development, from reading through the related LLVM code when implementing LDC/MinGW exception handling I'm fairly sure that SJLJ-style exception handling is used there. At least, the extra function calls emitted in the fast (non-EH) path are a sure sign that it is not the standard DWARF scheme.

Why would you think otherwise, Jacob? Including more context with your messages would make a fair amount of them infinitely more useful…

> 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?

They are for (un)registering the exception handling context with the global table of active handlers. The parameter to _Unwind_SjLj_Register is constructed by the setjmp() part of SJLJ (it's in fact an optimized, inlined version instead of an actual function call).  When an exception is raised, this global linked list is walked, calling the personality functions for the respective entries to determine whether to longjmp to them.

> I read llvm source code for a while yesterday and really haven't wrapped by brain around it yet.

I'd start out by getting a feel for the LLVM IR we need to generate.
For this, you can have a look at the respective Clang output (-S
-emit-llvm). The LLVM docs also have a page on the subject, but
unfortunately, it is rather sparse:
http://llvm.org/docs/ExceptionHandling.html#setjmp-longjmp-exception-handling

The more involved part will likely be to get the personality function
right. Fortunately, at least the related parts of libunwind are open
source: http://www.opensource.apple.com/source/libunwind/libunwind-35.3/src/Unwind-sjlj.c.
The source for the GCC/Clang personality function
(__gxx_personality_sj0) is probably available somewhere as well, but I
don't know where to look right now (libc++, probably).

David

January 06, 2014
On Mon, Jan 6, 2014 at 2:06 PM, David Nadlinger <code@klickverbot.at> wrote:
> The source for the GCC/Clang personality function
> (__gxx_personality_sj0) is probably available somewhere as well, but I
> don't know where to look right now (libc++, probably).

Okay, I just had another short look, and libc++abi seems promising: https://github.com/llvm-mirror/libcxxabi/tree/master/src (inofficial GitHub mirror)

Note in particular cxa_personality.cpp and Unwind/Unwind-sljl.c.

David
January 06, 2014
On Monday, 6 January 2014 at 13:15:45 UTC, David Nadlinger wrote:
> On Mon, Jan 6, 2014 at 2:06 PM, David Nadlinger <code@klickverbot.at> wrote:
>> The source for the GCC/Clang personality function
>> (__gxx_personality_sj0) is probably available somewhere as well, but I
>> don't know where to look right now (libc++, probably).
>
> Okay, I just had another short look, and libc++abi seems promising:
> https://github.com/llvm-mirror/libcxxabi/tree/master/src (inofficial
> GitHub mirror)
>
> Note in particular cxa_personality.cpp and Unwind/Unwind-sljl.c.
>
> David

Source for __gxx_personality_sj0 is part of gcc. Just download latest gcc source and search for the symbol.

Regards,
Kai
« First   ‹ Prev
1 2 3 4 5 6 7