Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 04, 2014 iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dan Olson | 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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
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 Re: iphone + LDC, a new ARM adventure | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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
|
Copyright © 1999-2021 by the D Language Foundation