any successfull ghc registerised builds on arm?

[Austin Seipp]

(CC'ing glasgow-haskell-users, as it got lost somehow. A message or
two from me and Karel are also missing the list.)

On Mon, Jan 14, 2013 at 1:27 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> Austin Seipp <mad.one at gmail.com> writes:
>
>> I've been working on ARM the past weekend. Here's where I'm at
>> (semi-long email ahead.)
>>
> I've also been working on this slowly over the last few weeks (in all of
> the discussion below, I'm building for a Pandaboard with Ubuntu's ghc
> 7.4 package). Unfortunately, most of my efforts have been going into
> convincing llc and gcc to build compatible objects. With GHC 7.6 simply
> taking the brute force approach with SRC_HC_OPTS seems to work,
>
>     SRC_HC_OPTS        = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-mcpu=cortex-a9 # -optlc-float-abi=hard
>
> With this, I can produce a compiler and run the testsuite to generate
> this not-entirely-depressing picture,
>
>     OVERALL SUMMARY for test run started at Sat Jan  5 17:12:12 UTC 2013
>         3400 total tests, which gave rise to
>         8322 test cases, of which
>            4 caused framework failures
>         5311 were skipped
>
>         2649 expected passes
>           47 had missing libraries
>           59 expected failures
>            0 unexpected passes
>          252 unexpected failures
>
> Sadly a good portion of the failures seem to be due to ghci crashing due
> to either a segmentation fault or illegal instruction.
> This is likely due to linker support needing either to be written or
> fixed. I'll have to brush off my linker knowledge and have a look at
> these (probably next weekend).

Yes, the linker bit was one of the components of the stage2 compiler
worrying me the most, especially since in our past conversations,
we've both seen it segfault when linking libraries while building
things like vector. I really can't wait for a future where GHC on
Linux supports dynamic by default out of the box (and ARM should fit
in this category, too.)

> In my opinion it's worth having a released compiler built as a refernce. The
> ghc-7.6 branch is pretty easy to get going if you ever have some spare
> CPU cycles available.

Spare cycles do occur sometimes, so I'll give a shot to building it
with LLVM-3.0 later when I get the chance.

>> Overall I think squashing as many bugs as possible in HEAD is the
>> correct route at the moment. This is only my opinion. My plans are to
>> get a working stage1 registered GHC HEAD, and begin running the
>> testsuite against it, filing down bugs. Eventually, this should lead
>> to a stage2 as we narrow things down.
>>
> Is this to say that you've been unable to successfully build a stage 2
> compiler? I'm currently in the middle of a build of HEAD. We'll see how
> far this makes it.

Yes, on my ODROID I have yet to build a stage2 compiler. This is
mostly due to bugs in the LLVM backend in combination with the new
code generator, it seems. I get through the entire stage1 build and
the build of several of the libraries, but now I'm stuck compiling
base with stage1. This is the bug I have yet to fix, in this area:

http://hackage.haskell.org/trac/ghc/ticket/7575

I speculate the cause of this bug is eerily similar to the other two
bugs I fixed relating to properly narrowing/widening LLVM variable
types. Take a look at these bugs and their patches:

http://hackage.haskell.org/trac/ghc/ticket/7571
http://hackage.haskell.org/trac/ghc/ticket/7580

so I imagine I can get this fixed tonight and move on.

> Out of curiosity, what are the build times on the ODROID?

I haven't completed a full build so it's hard to estimate. But with a
quick build and 'make -j4', the build seems to chug along fairly
respectably, and I'd say I can get through the entire stage1 compiler
build in the ballpark of ~30ish minutes. This is a very rough estimate
because with enough parallelism, it's hard to see "how far" you are in
the build, obviously. At a guess, I speculate a full build of
everything at -j4 would be somewhere on the order of an hour and a
half, to two-plus hours.

> I agree that having nightly buildbots would be very nice. I meant to
> setup my PandaBoard in this capacity after finishing my linker work, but
> sadly life and hardware failures got in the way.

Yes, PandaBoards aren't the most reliable as several of us seem to
realize. :) Anything you could contribute here would be wonderful. I'm
new to the buildbot infrastructure, so when the "time is right" I'll
rally people about this again.

> Very true. It would be very nice if we could handle this issue
> automatically after we figure out the proper way to handle it manually.

I think Karel is right that we may be able to get 90% of the way there
with a short hack in DriverPipeline, with some ./configure logic to
fix it, but easier said than done, I'm sure (abusrdly long build times
don't help I bet.)

> To be fair, hacking on the compiler itself is a bit sexier than hacking
> on the build system.

There are also considerably fewer variables named things like '$$$$$'
and '@$$$$' in the compiler than build system, which certainly helps
*me*, at least. :)

> Historically I've written up my experience on my own nearly non-existent
> blog[1][2][3]. Given the vanishingly small probability that someone will
> actually find this information, I think I'll start trying to put
> together a page on the Wiki instead. I agree that having a centralized
> location to place this sort of information is extremely valuable. A good
> portion of the effort in starting a project like this is determining
> what others have done.
>
> There already exists a ArmLinuxGhc[4] page on the wiki. That being said,
> it's woefully out of date and much of the discussion centers around
> other Haskell implementations. I'd say it would be fair to start with a
> clean slate on this page and describe the current state of things, the
> ideosyncracies of building GHC on ARM (e.g. float ABI issues), and what
> remains to be done (a list of failing tests when the reason for failure
> is known might be useful).
>
> Cheers,
>
> - Ben

Agreed. I'll look into cleaning up the wiki page later with a good
outline, so hopefully more users can contribute.

>
> [1] http://bgamari.github.com/posts/2013-01-04-ghc-arm-update.html
> [2] http://bgamari.github.com/posts/2012-01-27-ghc-llvm-arm.html
> [3] http://bgamari.github.com/posts/2011-10-17-crosscompiling_llvm.html
> [4] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc



-- 
Regards,
Austin