<div dir="ltr">I've pushed my WIP patches here:<div><a href="https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5">https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5</a><br>
</div><div><a href="https://github.com/lukexi/ghc/commit/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e">https://github.com/lukexi/ghc/commit/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e</a><br></div><div>(they also require the latest libffi to be dropped in <a href="ftp://sourceware.org/pub/libffi/libffi-3.0.13.tar.gz">ftp://sourceware.org/pub/libffi/libffi-3.0.13.tar.gz</a> due to <a href="https://ghc.haskell.org/trac/ghc/ticket/8664">https://ghc.haskell.org/trac/ghc/ticket/8664</a>)</div>
<div><br></div><div>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.</div>
<div><br></div><div>It looks like it's jumping somewhere strange; lldb tells me it's to</div><div><div>0x100e05110: .long 0x00000000 ; unknown opcode</div><div>0x100e05114: .long 0x00000000 ; unknown opcode</div>
<div>0x100e05118: .long 0x00000000 ; unknown opcode</div><div>0x100e0511c: .long 0x00000000 ; unknown opcode</div><div>0x100e05120: .long 0x00000000 ; unknown opcode</div>
<div>0x100e05124: .long 0x00000000 ; unknown opcode</div><div>0x100e05128: .long 0x00000000 ; unknown opcode</div><div>0x100e0512c: .long 0x00000000 ; unknown opcode</div>
</div><div><br></div><div>If I put a breakpoint on StgRun and step by instruction, I seem to make it to about:</div><div><a href="https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770">https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770</a><br>
</div><div>(give or take a line)</div><div>before something goes mysteriously wrong and I'm no longer able to interact with the debugger.</div><div><br></div><div>So I guess I'll try taking out float register support and see if that gets me anywhere.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers</div><div>Luke</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 6:44 PM, Luke Iannini <span dir="ltr"><<a href="mailto:lukexipd@gmail.com" target="_blank">lukexipd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">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.</span><div>
<font color="#000000" face="Helvetica"><span style="font-size:12px"><br></span></font><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">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. </div>
<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">So I've just gone ahead and defined them sequentially for now which seems to get me past this.</div>
</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Thanks!</div><span class="HOEnZb"><font color="#888888"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">
Luke</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas <span dir="ltr"><<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 08/ 9/14 05:27 AM, Luke Iannini wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Karel,<br>
Thanks!<br>
<br>
A question:<br>
<a href="https://git.haskell.org/ghc.git/commitdiff/454b34cb3b67dec21f023339c4d53d734af7605d" target="_blank">https://git.haskell.org/ghc.<u></u>git/commitdiff/<u></u>454b34cb3b67dec21f023339c4d53d<u></u>734af7605d</a><br>
adds references to s16, s17, s18, s19, d10 and d11 but I don't see those<br>
</blockquote>
<br></div>
Yes, that adds FPU support for ARM.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
where I though to expect them in<br>
<a href="https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs" target="_blank">https://github.com/ghc/ghc/<u></u>blob/master/includes/CodeGen.<u></u>Platform.hs</a><br>
</blockquote>
<br></div>
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.<br>
<br>
Cheers,<br>
Karel<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>