ARM linker support!

[Karel Gardas]

Ben,

big congratulations! And thanks a lot for your hard work on this. This 
is indeed really great!

I'm looking at your patch for #5824 and will have few questions in 
another email. I hope once this is solved I'll rerun your GHC tree 
thorough my testing board here...

Thanks!
Karel

On 01/29/12 06:21 PM, Ben Gamari wrote:
> Yesterday I finally had a large block of time to devote to the ARM
> linker. While I spent a large fraction of the day tracking down an
> unrelated bug (ticket #5824, David, your feedback would be greatly
> appreciated here), the linker is looking quite good,
>
>    $ inplace/lib/ghc-stage2 -B/opt/ghc/ghc/ghc/inplace/lib --interactive +RTS -N1
>    GHCi, version 7.4.0.20120126: http://www.haskell.org/ghc/  :? for help
>    Loading package ghc-prim ... linking ... done.
>    Loading package integer-gmp ... linking ... done.
>    Loading package base ... linking ... done.
>    Prelude>  print "hello world!"
>    "hello world!"
>    Prelude>  import System.IO
>    Prelude System.IO>  writeFile "asdf" "Hello World"
>    Prelude System.IO>
>    Leaving GHCi.
>
> Quite exciting! I've pushed the latest state of my tree to Github
> (http://www.github.com/bgamari/ghc/arm-ghci-7.4). As you might infer
> from the URL, I'm now working on top of the ghc-7.4 branch. I just got
> things working a few minutes ago, so the code isn't too well tested, but
> must be pretty close to correct to get as far as it does. The code needs
> to be cleaned up (whitespace fixed, debug output removed) and there is
> still an instruction decoding issue that I need to figure out, but I'd
> say things are looking pretty good.
>
> I've been testing against a very recent LLVM commit (git
> 7750ff1e3cbb87e68f406e6fa7c43a80a61a0ccb, svn commit 149182) which fails
> fewer tests than the 3.0 release and seems to emit reasonable code.
> While you're looking at patches, have a look at ticket #5814 which adds
> support for LLVM's "fence" instruction, added in the 3.0 release. The
> patch appears to work but I'm unsure of the exact syncronization
> requirements imposed by the Cmm barrier primitive. Also, I currently
> always emit "fence", where we should revert to using the
> "llvm.memory.barrier" intrinsic used<3.0.
>
> I'd appreciate any comments on any of the above.
>
> Cheers,
>
> - Ben
>