[Haskell-cafe] Clearing up the status of GHCi on Raspberry Pi

[Ben Gamari]

Dan Krol <orblivion at gmail.com> writes:

...
> I figure we should sort this out, I'd be happy to edit the wikis myself but
> I want to make sure I understand what's going on. I understand this
> probably comes down to some nuances that are not expressed here. For user
> friendliness of the language and ecosystem I think such things should be
> made clear. As somebody coming to this wanting to accomplish something, I
> want a clear answer on what is available to me. It's been a source of
> frustration for me.
>
> Could somebody clear all this up for me? And while I'm at it, I would be
> grateful if somebody could explain to me how it is possible (if at all) to
> have ghci on my Raspberry Pi, short of compiling it myself. I'm not against
> compiling ghc, but I am against compiling it on my Raspberry Pi. Qemu I
> will consider, though.
>
The situation is a bit complicated and I've been pretty poor at keeping
the existing documentation up-to-date. ARM support has in principle existed
in the tree through the LLVM code generator for some time. The code
generator itself is in my experience quite robust.

There are, however, a number of details in the runtime system which
break GHCi. One of these is the runtime linker which until recently had
effectively no support for ARM. I worked some initial ARM support in to
7.6.1 (b22501b408ddb0503a06a188b06d9cff9be697cd) and while things
largely worked at the time, there were still some rough edges. For this
reason, 7.6 can't really considered to support GHCi on ARM.
Unfortunately at this point I became quite busy and didn't have time to
look into the remaining issues. This was in late 2011.

In the last few weeks I've had time to have another look at this
problem. It turns out one of the issues (lack of jump code, documented
in bug #8380) was quite straightforward to fix
(up to some cache coherency issues which I believe thoughtpolice has now
sorted out, see 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd). Unfortunately
after fixing this I found that there was still occassional crashes
during the build process. I spent a fair bit of time poking around
looking for the root cause but have still come up with no compelling
leads. It's very likely that the culprit is the runtime linker, although
I haven't found a way to narrow things down any further.

Frankly, implementing a runtime linker is non-trivial business and in my
opinion the limited man-hours working on GHC are better spent
elsewhere. Having our own runtime linker has its advantages, but for an
architecture that is currently *barely* supported, it makes more sense
to punt as much of this responsibility to other parties as possible. For
this reason I think it would be wise to focus on moving this
functionality to the system's runtime linker by using dynamic linking.

Dynamic linking has been working for some time now on x86 with the
native code generator. Unfortunately, there have been rumors that things
are broken when the LLVM code generator is used (which is the only
option on ARM). I started looking into this late last week and believe I
have the problem identified (thanks to help from Peter Wortmann, see
[1]) and have something of a solution. At this point I'm running into
build system issues[2] which prevent me from verifying my hacked
work-around^H^H^Hsolution.

Assuming that I can validate the fix, I'm hoping there's a chance it (or
something like it) can make it in to 7.8. As far as I can tell, this is
the last major impediment to have GHC working well on ARM. Moreover, by
switching to dynamic linking on ARM we will have eliminated a major
source of trouble from the equation. This would mean that 7.8 would
finally have (hopefully) robust support on ARM.

Cheers,

- Ben


[1] http://www.haskell.org/pipermail/ghc-devs/2013-December/003484.html
[2] http://www.haskell.org/pipermail/ghc-devs/2013-December/003488.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131216/e5fd40aa/attachment.sig>