Re: ARM64 Task Force
That’s awesome — great work! Manuel Luke Iannini : > 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 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 0x000100f05110 frame > values. > (lldb) bt > * thread #1: tid = 0xac6ed, 0x000100f05110, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x100f05110) > frame #0: 0x000100f05110 > frame #1: 0x000100f05110 > * frame #2: 0x0001000ffc9c HelloHaskell`-[SPJViewController > viewDidLoad](self=0x000144e0cf10, _cmd=0x000186ae429a) + 76 at > SPJViewController.m:22 > frame #3: 0x0001862f8b70 UIKit`-[UIViewController loadViewIfRequired] > + 692 > frame #4: 0x0001862f8880 UIKit`-[UIViewController view] + 32 > frame #5: 0x0001862feeb0 UIKit`-[UIWindow > addRootViewControllerViewIfPossible] + 72 > frame #6: 0x0001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 > frame #7: 0x00018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 > frame #8: 0x00018657ff74 UIKit`-[UIApplication > _callInitializationDelegatesForMainScene:transitionContext:] + 2804 > frame #9: 0x0001865824ec UIKit`-[UIApplication > _runWithMainScene:transitionContext:completion:] + 1480 > frame #10: 0x000186580b84 UIKit`-[UIApplication > workspaceDidEndTransaction:] + 184 > frame #11: 0x000189d846ac FrontBoardServices`__31-[FBSSerialQueue > performAsync:]_block_invoke + 28 > frame #12: 0x000181c7a360 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 > frame #13: 0x000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 > frame #14: 0x000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 > frame #15: 0x000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 > frame #16: 0x000186363140 UIKit`-[UIApplication _run] + 552 > frame #17: 0x00018635e164 UIKit`UIApplicationMain + 1488 > frame #18: 0x000100100268 HelloHaskell`main(argc=1, > argv=0x00016fd07a58) + 204 at main.m:24 > frame #19: 0x0001921eea08 libdyld.dylib`start + 4 > > > > On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas > 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 0x ; unknown opcode > 0x100e05114: .long 0x ; unknown opcode > 0x100e05118: .long 0x ; unknown opcode > 0x100e0511c: .long 0x ; unknown opcode > 0x100e05120: .long 0x ; unknown opcode > 0x100e05124: .long 0x ; unknown opcode > 0x100e05128: .long 0x ; unknown opcode > 0x100e0512c: .long 0x ; 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
Re: ARM64 Task Force
Luke Iannini writes: > 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. > Yay! Awesome work! Cheers, - Ben pgpC53b1AIFVm.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
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 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 0x000100f05110 > frame values. > (lldb) bt > * thread #1: tid = 0xac6ed, 0x000100f05110, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x100f05110) > frame #0: 0x000100f05110 > frame #1: 0x000100f05110 > * frame #2: 0x0001000ffc9c HelloHaskell`-[SPJViewController > viewDidLoad](self=0x000144e0cf10, _cmd=0x000186ae429a) + 76 at > SPJViewController.m:22 > frame #3: 0x0001862f8b70 UIKit`-[UIViewController > loadViewIfRequired] + 692 > frame #4: 0x0001862f8880 UIKit`-[UIViewController view] + 32 > frame #5: 0x0001862feeb0 UIKit`-[UIWindow > addRootViewControllerViewIfPossible] + 72 > frame #6: 0x0001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 > frame #7: 0x00018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 > frame #8: 0x00018657ff74 UIKit`-[UIApplication > _callInitializationDelegatesForMainScene:transitionContext:] + 2804 > frame #9: 0x0001865824ec UIKit`-[UIApplication > _runWithMainScene:transitionContext:completion:] + 1480 > frame #10: 0x000186580b84 UIKit`-[UIApplication > workspaceDidEndTransaction:] + 184 > frame #11: 0x000189d846ac FrontBoardServices`__31-[FBSSerialQueue > performAsync:]_block_invoke + 28 > frame #12: 0x000181c7a360 > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 > frame #13: 0x000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 > frame #14: 0x000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 > frame #15: 0x000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 > frame #16: 0x000186363140 UIKit`-[UIApplication _run] + 552 > frame #17: 0x00018635e164 UIKit`UIApplicationMain + 1488 > frame #18: 0x000100100268 HelloHaskell`main(argc=1, > argv=0x00016fd07a58) + 204 at main.m:24 > frame #19: 0x0001921eea08 libdyld.dylib`start + 4 > > > > On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas > 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 0x ; unknown opcode >>> 0x100e05114: .long 0x ; unknown opcode >>> 0x100e05118: .long 0x ; unknown opcode >>> 0x100e0511c: .long 0x ; unknown opcode >>> 0x100e05120: .long 0x ; unknown opcode >>> 0x100e05124: .long 0x ; unknown opcode >>> 0x100e05128: .long 0x ; unknown opcode >>> 0x100e0512c: .long 0x ; 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 >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
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 0x000100f05110 frame values. (lldb) bt * thread #1: tid = 0xac6ed, 0x000100f05110, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x100f05110) frame #0: 0x000100f05110 frame #1: 0x000100f05110 * frame #2: 0x0001000ffc9c HelloHaskell`-[SPJViewController viewDidLoad](self=0x000144e0cf10, _cmd=0x000186ae429a) + 76 at SPJViewController.m:22 frame #3: 0x0001862f8b70 UIKit`-[UIViewController loadViewIfRequired] + 692 frame #4: 0x0001862f8880 UIKit`-[UIViewController view] + 32 frame #5: 0x0001862feeb0 UIKit`-[UIWindow addRootViewControllerViewIfPossible] + 72 frame #6: 0x0001862fc6d4 UIKit`-[UIWindow _setHidden:forced:] + 296 frame #7: 0x00018636d2bc UIKit`-[UIWindow makeKeyAndVisible] + 56 frame #8: 0x00018657ff74 UIKit`-[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 2804 frame #9: 0x0001865824ec UIKit`-[UIApplication _runWithMainScene:transitionContext:completion:] + 1480 frame #10: 0x000186580b84 UIKit`-[UIApplication workspaceDidEndTransaction:] + 184 frame #11: 0x000189d846ac FrontBoardServices`__31-[FBSSerialQueue performAsync:]_block_invoke + 28 frame #12: 0x000181c7a360 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 20 frame #13: 0x000181c79468 CoreFoundation`__CFRunLoopDoBlocks + 312 frame #14: 0x000181c77a8c CoreFoundation`__CFRunLoopRun + 1756 frame #15: 0x000181ba5664 CoreFoundation`CFRunLoopRunSpecific + 396 frame #16: 0x000186363140 UIKit`-[UIApplication _run] + 552 frame #17: 0x00018635e164 UIKit`UIApplicationMain + 1488 frame #18: 0x000100100268 HelloHaskell`main(argc=1, argv=0x00016fd07a58) + 204 at main.m:24 frame #19: 0x0001921eea08 libdyld.dylib`start + 4 On Tue, Aug 12, 2014 at 11:24 AM, Karel Gardas 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 0x ; unknown opcode >> 0x100e05114: .long 0x ; unknown opcode >> 0x100e05118: .long 0x ; unknown opcode >> 0x100e0511c: .long 0x ; unknown opcode >> 0x100e05120: .long 0x ; unknown opcode >> 0x100e05124: .long 0x ; unknown opcode >> 0x100e05128: .long 0x ; unknown opcode >> 0x100e0512c: .long 0x ; 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 > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
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 0x ; unknown opcode 0x100e05114: .long 0x ; unknown opcode 0x100e05118: .long 0x ; unknown opcode 0x100e0511c: .long 0x ; unknown opcode 0x100e05120: .long 0x ; unknown opcode 0x100e05124: .long 0x ; unknown opcode 0x100e05128: .long 0x ; unknown opcode 0x100e0512c: .long 0x ; 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
Re: ARM64 Task Force
I've pushed my WIP patches here: https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5 https://github.com/lukexi/ghc/commit/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e (they also require the latest libffi to be dropped in ftp://sourceware.org/pub/libffi/libffi-3.0.13.tar.gz due to https://ghc.haskell.org/trac/ghc/ticket/8664) These can produce an ARM64 GHC but the produced binaries aren't fully functional yet. They make it through hs_init() but crash rather opaquely when I try to call a simple fib function through the FFI. It looks like it's jumping somewhere strange; lldb tells me it's to 0x100e05110: .long 0x; unknown opcode 0x100e05114: .long 0x; unknown opcode 0x100e05118: .long 0x; unknown opcode 0x100e0511c: .long 0x; unknown opcode 0x100e05120: .long 0x; unknown opcode 0x100e05124: .long 0x; unknown opcode 0x100e05128: .long 0x; unknown opcode 0x100e0512c: .long 0x; 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) before something goes mysteriously wrong and I'm no longer able to interact with the debugger. So I guess I'll try taking out float register support and see if that gets me anywhere. If anyone has some ideas on how to debug this I'd love to hear them! I've mostly assembled the patches by adapting the existing ARM support so it's quite possibly I'm doing something boneheaded. Cheers Luke On Sun, Aug 10, 2014 at 6:44 PM, Luke Iannini wrote: > I think I've solved this particular mystery -- the registers were never > defined there because that integer-representation of them is only used by > the NCG. In LLVM land they were only ever stringified by the REG() macro. > > Except now globalRegMaybe is being used in CmmSink.hs (as Simon and Ben > were discussing), and globalRegMaybe needs an integer value for each > register to put into its Maybe RealReg return value. Since CmmSink.hs only > checks 'isJust', it doesn't actually matter what the integer value is. > > So I've just gone ahead and defined them sequentially for now which seems > to get me past this. > > Thanks! > Luke > > > On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas > wrote: > >> On 08/ 9/14 05:27 AM, Luke Iannini wrote: >> >>> Hi Karel, >>> Thanks! >>> >>> A question: >>> https://git.haskell.org/ghc.git/commitdiff/ >>> 454b34cb3b67dec21f023339c4d53d734af7605d >>> adds references to s16, s17, s18, s19, d10 and d11 but I don't see those >>> >> >> Yes, that adds FPU support for ARM. >> >> >> where I though to expect them in >>> https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs >>> >> >> Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were >> discussing this with Ben Gamari recently. I've not investigated if this is >> needed or not since I don't know if this is used only in NCG or in >> registerised build in general. If the former, ARM will not be there as >> there is no ARM NCG yet, if the later, then ARM should be there as >> ARM/LLVM/registerised build is a reality. >> >> Cheers, >> Karel >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
I think I've solved this particular mystery -- the registers were never defined there because that integer-representation of them is only used by the NCG. In LLVM land they were only ever stringified by the REG() macro. Except now globalRegMaybe is being used in CmmSink.hs (as Simon and Ben were discussing), and globalRegMaybe needs an integer value for each register to put into its Maybe RealReg return value. Since CmmSink.hs only checks 'isJust', it doesn't actually matter what the integer value is. So I've just gone ahead and defined them sequentially for now which seems to get me past this. Thanks! Luke On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas wrote: > On 08/ 9/14 05:27 AM, Luke Iannini wrote: > >> Hi Karel, >> Thanks! >> >> A question: >> https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d >> 734af7605d >> adds references to s16, s17, s18, s19, d10 and d11 but I don't see those >> > > Yes, that adds FPU support for ARM. > > > where I though to expect them in >> https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs >> > > Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were > discussing this with Ben Gamari recently. I've not investigated if this is > needed or not since I don't know if this is used only in NCG or in > registerised build in general. If the former, ARM will not be there as > there is no ARM NCG yet, if the later, then ARM should be there as > ARM/LLVM/registerised build is a reality. > > Cheers, > Karel > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
On 08/ 9/14 05:27 AM, Luke Iannini wrote: Hi Karel, Thanks! A question: https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d734af7605d adds references to s16, s17, s18, s19, d10 and d11 but I don't see those Yes, that adds FPU support for ARM. where I though to expect them in https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were discussing this with Ben Gamari recently. I've not investigated if this is needed or not since I don't know if this is used only in NCG or in registerised build in general. If the former, ARM will not be there as there is no ARM NCG yet, if the later, then ARM should be there as ARM/LLVM/registerised build is a reality. Cheers, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
Hi Karel, Thanks! A question: https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d734af7605d adds references to s16, s17, s18, s19, d10 and d11 but I don't see those where I though to expect them in https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs Am I down a wrong path? Luke On Thu, Aug 7, 2014 at 10:58 PM, Karel Gardas wrote: > On 08/ 8/14 01:58 AM, Luke Iannini wrote: > >> I'm now studying David's patches to LLVM to learn how to add the >> ARM64/GHC calling convention to LLVM. >> > > Here is also original ARM/GHC calling convention submission. It's always > good to have more examples as reference... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html > > Good luck with the ARM64/GHC porting work! > > Karel > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
On 08/ 8/14 01:58 AM, Luke Iannini wrote: I'm now studying David's patches to LLVM to learn how to add the ARM64/GHC calling convention to LLVM. Here is also original ARM/GHC calling convention submission. It's always good to have more examples as reference... http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html Good luck with the ARM64/GHC porting work! Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
Hi all, An update on this -- I've made a bit of progress thanks to Karel and Colin's start at ARM64 support https://ghc.haskell.org/trac/ghc/ticket/7942 With a few tweaks*, that let me build a GHC that builds ARM64 binaries and load them onto my iPad Air, which is great! But of course they don't work yet since LLVM doesn't have the ARM64/GHC calling convention in. Happily I was able to use LLVM HEAD to do this, which means we don't need to be bound to Xcode's release schedules. I'm now studying David's patches to LLVM to learn how to add the ARM64/GHC calling convention to LLVM. *including Ben Gamari's patches to get LLVM HEAD working https://github.com/bgamari/ghc/tree/llvm-3.5-new Best Luke On Mon, Jul 7, 2014 at 11:06 PM, Luke Iannini wrote: > Howdy all, > > Would anyone like to team up on getting ARM64 support into GHC? > > Cheers > Luke > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
ARM64 Task Force
Howdy all, Would anyone like to team up on getting ARM64 support into GHC? Cheers Luke ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
