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

[Dan Krol]

If I could edit the haskellwiki I would just link to the archive of Ben's
email. Unfortunately I don't see a register button for the wiki. Could
somebody else do it? Or is there a way for an arbitrary person like me to
get an account with edit privileges?


On Tue, Dec 17, 2013 at 9:29 AM, Dan Krol <orblivion at gmail.com> wrote:

> Thanks so much for the detailed response. When I have a moment I will try
> to come up with some appropriate edits to the Wikis, I will run them by you
> first to make sure they're accurate. And even moreso, thanks for your work
> in this area. When is 7.8 looking like it's coming out? And, how hard would
> it be to install it onto my Pi? Would I have to compile it? I'm assuming it
> won't make it into the Jesse repository (or will it?)
>
> -Dan
>
>
> On Mon, Dec 16, 2013 at 8:22 AM, Ben Gamari <bgamari.foss at gmail.com>wrote:
>
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131221/708441eb/attachment.html>