ARM64 Task Force

Luke Iannini lukexipd at gmail.com
Thu Aug 14 00:26:00 UTC 2014


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 <lukexipd at 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.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/20140813/e886bbfd/attachment.html>


More information about the ghc-devs mailing list