That’s awesome — great work! Manuel
Luke Iannini <lukex...@gmail.com>: > Indeed, the float register stuff was a red herring — restoring it caused no > problems and all my tests are working great. So yahoo!! We've got ARM64 > support. > > I'll tidy up the patches and create a ticket for review and merge. > > Luke > > > On Tue, Aug 12, 2014 at 4:47 PM, Luke Iannini <lukex...@gmail.com> wrote: > Hi all, > Yahoo, happy news — I think I've got it. Studying enough of the > non-handwritten ASM that I was stepping through led me to make this change: > https://github.com/lukexi/ghc/commit/1140e11db07817fcfc12446c74cd5a2bcdf92781 > (I think disabling the floating point registers was just a red herring; I'll > confirm that next) > > And I can now call this fib code happily via the FFI: > fibs :: [Int] > fibs = 1:1:zipWith (+) fibs (tail fibs) > > foreign export ccall fib :: Int -> Int > fib :: Int -> Int > fib = (fibs !!) > > For posterity, more detail on the crashing case earlier (this is fixed now > with proper storage and updating of the frame pointer): > Calling fib(1) or fib(2) worked, but calling fib(3) triggered the crash. > This was the backtrace, where you can see the errant 0x0000000100f05110 frame > values. > (lldb) bt > * thread #1: tid = 0xac6ed, 0x0000000100f05110, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x100f05110) > frame #0: 0x0000000100f05110 > frame #1: 0x0000000100f05110 > * frame #2: 0x00000001000ffc9c HelloHaskell`-[SPJViewController > viewDidLoad](self=0x0000000144e0cf10, _cmd=0x0000000186ae429a) + 76 at > SPJViewController.m:22 > frame #3: 0x00000001862f8b70 UIKit`-[UIViewController loadViewIfRequired] > + 692 > frame #4: 0x00000001862f8880 UIKit`-[UIViewController view] + 32 > frame #5: 0x00000001862feeb0 UIKit`-[UIWindow > addRootViewControllerViewIfPossible] + 72 > frame #6: 0x00000001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 > frame #7: 0x000000018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 > frame #8: 0x000000018657ff74 UIKit`-[UIApplication > _callInitializationDelegatesForMainScene:transitionContext:] + 2804 > frame #9: 0x00000001865824ec UIKit`-[UIApplication > _runWithMainScene:transitionContext:completion:] + 1480 > frame #10: 0x0000000186580b84 UIKit`-[UIApplication > workspaceDidEndTransaction:] + 184 > frame #11: 0x0000000189d846ac FrontBoardServices`__31-[FBSSerialQueue > performAsync:]_block_invoke + 28 > frame #12: 0x0000000181c7a360 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 > frame #13: 0x0000000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 > frame #14: 0x0000000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 > frame #15: 0x0000000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 > frame #16: 0x0000000186363140 UIKit`-[UIApplication _run] + 552 > frame #17: 0x000000018635e164 UIKit`UIApplicationMain + 1488 > frame #18: 0x0000000100100268 HelloHaskell`main(argc=1, > argv=0x000000016fd07a58) + 204 at main.m:24 > frame #19: 0x00000001921eea08 libdyld.dylib`start + 4 > > > > On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas <karel.gar...@centrum.cz> > wrote: > On 08/12/14 11:03 AM, Luke Iannini wrote: > It looks like it's jumping somewhere strange; lldb tells me it's to > 0x100e05110: .long 0x00000000 ; unknown opcode > 0x100e05114: .long 0x00000000 ; unknown opcode > 0x100e05118: .long 0x00000000 ; unknown opcode > 0x100e0511c: .long 0x00000000 ; unknown opcode > 0x100e05120: .long 0x00000000 ; unknown opcode > 0x100e05124: .long 0x00000000 ; unknown opcode > 0x100e05128: .long 0x00000000 ; unknown opcode > 0x100e0512c: .long 0x00000000 ; unknown opcode > > If I put a breakpoint on StgRun and step by instruction, I seem to make > it to about: > https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770 > (give or take a line) > > strange that it's in the middle of the stp isns block. Anyway, this looks > like a cpu exception doesn't it? You will need to find out the reg which > holds the "exception reason" value and then look on it in your debugger to > find out what's going wrong there. > > Karel > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
