ARM64 Task Force

[Luke Iannini]

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.gardas at 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/e99b7a41e64f3ddb9bb420c0d5583f
>> 0e302e321e/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140812/224360a9/attachment.html>