Re: GHC arm64 porting
On Tue, Apr 08, 2014 at 05:20:02PM +0200, Joachim Breitner wrote:
> Am Samstag, den 05.04.2014, 10:34 +0200 schrieb Joachim Breitner:
> > You can do it interactively. Keep running
> > $ darcs obliterate
> > and say "yes" to everything but "tagged 7.6.3-8". You need to iterate
> > that, darcs seems to stop asking after tags (dunno why), until it only
> > offers you that patch. Then you have reached that tag.
> >
> > Alternatively
> > $ darcs get ~/debian/pkg-haskell/repos/ghc --tag 7.6.3-8
> >
> > Then you can work as usual. You will, however, have to merge again
> > before pushing, which requires manual conflict resolution in
> > debian/changelog.
> >
> > If this sounds too annoying to learn let me know and I’ll do it.
>
> I guess that was the case, so I did in.
Thanks. It wasn't so much that it was too annoying as that I failed to
get round to it before you did. But I'm glad I didn't have to deal with
the darcs bug you hit. :-)
> > We could also start having separate repositories (= branches, in Darcs)
> > on alioth for unstable and experimental, as we used to have. At least
> > for ghc; I don’t expect much parallel development for the libraries.
>
> and you can either
> $ darcs get darcs.debian.org:/darcs/pkg-haskell/ghc
> or
> $ darcs get darcs.debian.org:/darcs/pkg-haskell/experimental/ghc
>
> We better merge them after a switch to git, it seems :-]
OK, sounds sensible.
Today I've managed to get ppc64el working as well. This turned out to
be connected to http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html:
declaring functions as taking zero arguments (rather than unspecified
arguments, at least failing an accurate prototype) causes GCC to
allocate the wrong amount of stack space in some cases, resulting in an
extremely confusing crash shortly after returning from functions that
take a sufficiently large number of arguments that some of them have to
be passed on the stack. Fortunately the fix is a one-liner, so in
addition to the obvious aclocal.m4 changes enabling this architecture
looks like this:
Index: b/aclocal.m4
===================================================================
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -173,7 +173,7 @@
GET_ARM_ISA()
test -z "[$]2" || eval "[$]2=\"ArchARM {armISA = \$ARM_ISA, armISAExt = \$ARM_ISA_EXT, armABI = \$ARM_ABI}\""
;;
- aarch64|alpha|mips|mipseb|mipsel|hppa|hppa1_1|ia64|m68k|rs6000|s390|s390x|sparc64|vax)
+ aarch64|alpha|mips|mipseb|mipsel|hppa|hppa1_1|ia64|m68k|powerpc64le|rs6000|s390|s390x|sparc64|vax)
test -z "[$]2" || eval "[$]2=ArchUnknown"
;;
*)
@@ -1868,6 +1868,9 @@
mips*)
$2="mips"
;;
+ powerpc64le*)
+ $2="powerpc64le"
+ ;;
powerpc64*)
$2="powerpc64"
;;
Index: b/includes/Stg.h
===================================================================
--- a/includes/Stg.h
+++ b/includes/Stg.h
@@ -213,7 +213,7 @@
#define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8))
#define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void)
#define FN_(f) StgFunPtr f(void)
-#define EF_(f) extern StgFunPtr f(void)
+#define EF_(f) extern StgFunPtr f()
/* -----------------------------------------------------------------------------
Tail calls
I've confirmed that this builds on all other Ubuntu architectures
(amd64, arm64, armhf, i386, powerpc), which should be pretty good
coverage; and I've also confirmed that it doesn't change ABI on any of
those. I have a native 7.8 build at this point and I'm working my way
through the build-7.6-using-7.8 step, which is going much quicker than
before since I can just apply the set of hacks I used before. Assuming
that my current build has produced a working 7.6 ghc-stage2 when I get
up tomorrow morning, and if nobody objects, I'll send this upstream to
https://ghc.haskell.org/trac/ghc/ticket/8965, get this into darcs, and
prepare another upload.
Interesting though this has been, after this I think I'll try to do
something that doesn't involve bootstrapping GHC for a bit. ;-)
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: