(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 wrote:

Austin Seipp 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