Status and future of the LLVM backend

Ben Gamari

29 Nov 2014 29 Nov '14

12:27 a.m.

I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12 * Austin's LLVM packaging proposal seems very much like the right way forward * Anticipating this proposal, I have started collecting [2] optimization passes Cheers, - Ben [1]: http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html [2]: https://github.com/bgamari/ghc-llvm-analyses

Attachments:

attachment.sig (application/pgp-signature — 472 bytes)

Show replies by date

Joachim Breitner

30 Nov 30 Nov

2:26 p.m.

Hi Ben, Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari:

...

I've written down some thoughts on the current status and future direction of the LLVM backend here [1].

thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) I then followed your advice from somewhere else and passed "--with-ld=ld.gold" to ./configure, but with the same effect: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20141119-4&stamp=1417223811 Any other tricks that could make GHC 7.8.4-rc1 compile on arm? (Including applying some not-yet-merged-patched, if necessary.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

4:56 p.m.

Joachim Breitner writes:

...

Hi Ben,

Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari:

...
I've written down some thoughts on the current status and future direction of the LLVM backend here [1].

thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux)

Indeed this looks like ld.bfd is being used.

...

I then followed your advice from somewhere else and passed "--with-ld=ld.gold" to ./configure, but with the same effect:

Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does. Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably. Cheers, - Ben [1] https://gist.github.com/bgamari/9399430

Joachim Breitner

6:56 p.m.

[Resent, as ghc-dev does not like my other address. Sorry Ben] Hi, Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:

...

...
thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux)

Indeed this looks like ld.bfd is being used.

hmm, that’s annoying that --with-ld does not do the right thing. Is there a bug reported about this?

...

...
I then followed your advice from somewhere else and passed "--with-ld=ld.gold" to ./configure, but with the same effect:

Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does.

hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html. What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

...

Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably.

What would be the symptoms of that problem? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

10:48 p.m.

Joachim Breitner writes:

...

[Resent, as ghc-dev does not like my other address. Sorry Ben]

Hi,

Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:

...
...
thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux)

Indeed this looks like ld.bfd is being used.

hmm, that’s annoying that --with-ld does not do the right thing. Is there a bug reported about this?

Not that I know of. It would be good if it did the right thing although I'm afraid that the gold issue described below means that it wouldn't make much difference in practice; I don't think we want to be in the business of building in hacks working around linker quirks into our build system.

...

...
...
I then followed your advice from somewhere else and passed "--with-ld=ld.gold" to ./configure, but with the same effect:

Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does.

hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.

What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk.

...

...
Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably.

What would be the symptoms of that problem?

You'll see an error message of the form, /usr/bin/ld.gold: error: /usr/lib/ghc/libHSrts.a(GetTime.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC I'm tempted to just try implementing this relocation type but sadly these sorts of patches always take longer to get right than I expect. Cheers, - Ben

Joachim Breitner

10:54 p.m.

Hi, Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:

...

...
...
...
I then followed your advice from somewhere else and passed "--with-ld=ld.gold" to ./configure, but with the same effect:

Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does.

hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.

What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk.

Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold? "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -lffi -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.2 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist-install/build -optl-L'/«PKGBUILDDIR»/libraries/filepath/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/containers/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/deepseq/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/array/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/base/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/integer-gmp/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/ghc-prim/dist-install/build' -optl-L'/«PKGBUILDDIR»/rts/dist/build' -optl-lgmp -optl-lm -optl-lrt -optl-ldl -optl-lffi -fPIC -dynamic -H32m -O -lffi -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.2 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split/dist-install/build/Main.dyn_o [..] "cp" -p utils/dll-split/dist-install/build/tmp/dll-split inplace/lib/bin/dll-split dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20141119-5&stamp=1417383951 Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

1 Dec 1 Dec

12:49 a.m.

Joachim Breitner writes:

...

Hi,

Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:

...
...
What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk.

Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold?

I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want SRC_HC_OPTS += -optl-B/usr/bin/ld.gold Hopefully this will do it; at least the option appears to make it to the right phase now. Is the Debian packaging tracked in version control somewhere? All I can find is the packaging tarball [1]. Cheers, - Ben [1] https://packages.debian.org/sid/ghc

Joachim Breitner

9:42 a.m.

Hi, Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:

...

...
Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:

...
...
What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk.

Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold?

I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want

SRC_HC_OPTS += -optl-B/usr/bin/ld.gold

Hopefully this will do it; at least the option appears to make it to the right phase now.

Trying it right now...

...

Is the Debian packaging tracked in version control somewhere? All I can find is the packaging tarball [1].

It’s at http://darcs.debian.org/pkg-haskell/experimental/ghc (but due to a index.html in that directory, you cannot browse it, so you have to "darcs get" it) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

2:28 p.m.

Hi, Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner:

...

Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:

...
...
Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:

...
...
What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea?

Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk.

Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold?

I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want

SRC_HC_OPTS += -optl-B/usr/bin/ld.gold

Hopefully this will do it; at least the option appears to make it to the right phase now.

Trying it right now...

no success, same error: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

7:17 p.m.

Joachim Breitner writes:

...

Hi,

Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner:

...
Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari:

...
I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want

SRC_HC_OPTS += -optl-B/usr/bin/ld.gold

Hopefully this will do it; at least the option appears to make it to the right phase now.

Trying it right now...

no success, same error: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20141119-6&stamp=1417438953&file=log

Is there any way you could poke around at the state of the tree after the failure? It would be nice to confirm that this is in fact that bfd/gold issue and perhaps figure out why ld.gold isn't being used. Otherwise I can try to reproduce this on my ARM box. Cheers, - Ben

Joachim Breitner

4 Dec 4 Dec

11:37 p.m.

Hi, Am Montag, den 01.12.2014, 13:17 -0500 schrieb Ben Gamari:

...

Is there any way you could poke around at the state of the tree after the failure? It would be nice to confirm that this is in fact that bfd/gold issue and perhaps figure out why ld.gold isn't being used.

Otherwise I can try to reproduce this on my ARM box.

ok, I finally reproduced this on a porter box, and (using strace...) I found out that -B/usr/bin/ld.gold was ignored. What did work was passing -optl-fuse-ld=gold to ghc. But that, in turn, causes /usr/bin/ld.gold: --hash-size=31: unknown option There seems to be some special handling for Gold in SysTools.lhs, via getLinkerInfo'. But passing -pgml=/usr/bin/ld.gold to ghc causes /usr/bin/ld.gold: -pthread: unknown option /usr/bin/ld.gold: use the --help option for usage information so this is not the right thing to do. The problem is that in order to find out which linker is used, ghc calls /usr/bin/gcc -Wl,-version without passing the options from -optl, so the -fuse-ld=gold is not used in this step. I’m a bit confused, because the code in getLinkerInfo' looks like it should be passing them... ah, but only on HEAD, not in 7.8... and git blame tells me that I probably want to apply this patch: commit e7b414a3cc0e27049f2608f5e0a00c47146cc46d Author: Sebastian Dröge Date: Tue Nov 18 12:40:20 2014 -0600 Fix detection of GNU gold linker if invoked via gcc with parameters Previously the linker was called without any commandline parameters to detect whether bfd or gold is used. However the -fuse-ld parameter can be used to switch between gold and bfd and should be taken into account here. Trac #9336 Signed-off-by: Austin Seipp (which would have saved me some work had I known about it). I’ll try it and report back. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

5 Dec 5 Dec

8:25 p.m.

Hi, Am Donnerstag, den 04.12.2014, 23:37 +0100 schrieb Joachim Breitner:

...

The problem is that in order to find out which linker is used, ghc calls

/usr/bin/gcc -Wl,-version

without passing the options from -optl, so the -fuse-ld=gold is not used in this step. I’m a bit confused, because the code in getLinkerInfo' looks like it should be passing them... ah, but only on HEAD, not in 7.8... and git blame tells me that I probably want to apply this patch:

commit e7b414a3cc0e27049f2608f5e0a00c47146cc46d Author: Sebastian Dröge Date: Tue Nov 18 12:40:20 2014 -0600

now gold is used, but if I set this in SRC_HC_OPTS, it is also passed to the bootstrapping compiler, which does not work with gold. So it seems I want to modify the "C compiler link flags" settings. I tried to achieve this using Index: ghc-7.8.20141119/aclocal.m4 =================================================================== --- ghc-7.8.20141119.orig/aclocal.m4 +++ ghc-7.8.20141119/aclocal.m4 @@ -553,6 +553,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. but this made the settings reach parts of the build system where I did not want them, and for example tips over configuring terminfo-0.4.0.0...: checking for setupterm in -ltinfo... yes configure: creating ./config.status config.status: creating terminfo.buildinfo configure: WARNING: unrecognized options: --with-compiler, --with-gcc ghc-cabal: Missing dependency on a foreign library: * Missing C library: tinfo This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. because --gcc-options=-fuse-ld=gold is being passed to ./configure. Now idea why that confuses ghc-cabal. Unfortunately, cabal is not very verbose and does not tell me why and how the test C program failed to compile.... but strace helps. And we are back at /usr/bin/ld.gold: --hash-size=31: unknown option But I’m not sure where this comes from. So, less elegantly, I’m now trying @@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], fi fi SettingsCCompilerFlags="$CONF_CC_OPTS_STAGE2" - SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2" + SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold" SettingsLdFlags="$CONF_LD_LINKER_OPTS_STAGE2" AC_SUBST(SettingsCCompilerCommand) AC_SUBST(SettingsHaskellCPPCommand) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

6 Dec 6 Dec

3:59 p.m.

Hi, Am Freitag, den 05.12.2014, 20:25 +0100 schrieb Joachim Breitner:

...

So, less elegantly, I’m now trying

@@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], fi fi SettingsCCompilerFlags="$CONF_CC_OPTS_STAGE2" - SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2" + SettingsCCompilerLinkFlags="$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold" SettingsLdFlags="$CONF_LD_LINKER_OPTS_STAGE2" AC_SUBST(SettingsCCompilerCommand) AC_SUBST(SettingsHaskellCPPCommand)

great, this works, and the build proceeds up to calling dll-split, and that does not crash as it did before. But it gives this error message: inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[2]: *** [compiler/stage2/dll-split.stamp] Error 1 any idea what might be causing this? I started the build from a fresh checkout. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

4:19 p.m.

Hi, Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner:

...

any idea what might be causing this? I started the build from a fresh checkout.

nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3... and will try with these. Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

5:06 p.m.

Joachim Breitner writes:

...

Hi,

Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner:

...
any idea what might be causing this? I started the build from a fresh checkout.

nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3... and will try with these.

Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4.

Excellent! Thanks for doing this. I wish I had been able to provide more guidance but the end of the semester has been a bit crazy. Cheers, - Ben

Joachim Breitner

7 Dec 7 Dec

11:07 a.m.

Hi, Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner:

...

nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3... and will try with these.

Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4.

and the build went further, I now have "inplace/bin/ghc-stage2" -o utils/haddock/dist/build/tmp/haddock -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -lffi -optl-pthread -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.2 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.3.20141119 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/xhtml/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/compiler/stage2/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/transformers/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/hpc/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/hoopl/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/bin-package-db/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/binary/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/Cabal/Cabal/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/process/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/pretty/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/directory/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/unix/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/time/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/old-locale/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/filepath/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/containers/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/bytestring/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/deepseq/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/array/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/base/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/integer-gmp/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/libraries/ghc-prim/dist-install/build' -optl-L'/home/nomeata/ghc-7.8.20141119/rts/dist/build' -optl-lrt -optl-lutil -optl-ldl -optl-lpthread -optl-lgmp -optl-lm -optl-lrt -optl-ldl -optl-lffi -fPIC -dynamic -H32m -O -lffi -optl-pthread -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.2 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.3.20141119 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../xhtml-3000.2.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-7.8.3.20141119' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../transformers-0.3.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hpc-0.6.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../hoopl-3.10.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bin-package-db-0.0.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../binary-0.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../Cabal-1.18.1.3' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../process-1.2.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../pretty-1.1.1.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../directory-1.2.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../unix-2.7.0.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../time-1.4.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../old-locale-1.0.0.6' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../bytestring-0.10.4.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/haddock/dist/build/Main.dyn_o utils/haddock/dist/build/Documentation/Haddock.dyn_o utils/haddock/dist/build/Data/Attoparsec.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.dyn_o utils/haddock/dist/build/Data/Attoparsec/Combinator.dyn_o utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.dyn_o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.dyn_o utils/haddock/dist/build/Data/Attoparsec/Internal.dyn_o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.dyn_o utils/haddock/dist/build/Haddock.dyn_o utils/haddock/dist/build/Haddock/Interface.dyn_o utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/dist/build/Haddock/Interface/AttachInstances.dyn_o utils/haddock/dist/build/Haddock/Interface/LexParseRn.dyn_o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.dyn_o utils/haddock/dist/build/Haddock/Parser.dyn_o utils/haddock/dist/build/Haddock/Parser/Util.dyn_o utils/haddock/dist/build/Haddock/Utf8.dyn_o utils/haddock/dist/build/Haddock/Utils.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.dyn_o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.dyn_o utils/haddock/dist/build/Haddock/Backends/LaTeX.dyn_o utils/haddock/dist/build/Haddock/Backends/HaddockDB.dyn_o utils/haddock/dist/build/Haddock/Backends/Hoogle.dyn_o utils/haddock/dist/build/Haddock/ModuleTree.dyn_o utils/haddock/dist/build/Haddock/Types.dyn_o utils/haddock/dist/build/Haddock/Doc.dyn_o utils/haddock/dist/build/Haddock/Version.dyn_o utils/haddock/dist/build/Haddock/InterfaceFile.dyn_o utils/haddock/dist/build/Haddock/Options.dyn_o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o utils/haddock/dist/build/Haddock/Convert.dyn_o utils/haddock/dist/build/Paths_haddock.dyn_o /home/nomeata/ghc-7.8.20141119/compiler/stage2/build/libHSghc-7.8.3.20141119-ghc7.8.3.20141119.so: error: undefined reference to 'arm_atomic_spin_lock' /home/nomeata/ghc-7.8.20141119/compiler/stage2/build/libHSghc-7.8.3.20141119-ghc7.8.3.20141119.so: error: undefined reference to 'arm_atomic_spin_unlock' collect2: error: ld returned 1 exit status utils/haddock/ghc.mk:15: recipe for target 'utils/haddock/dist/build/tmp/haddock' failed make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ben Gamari

8 Dec 8 Dec

2:20 p.m.

Joachim Breitner writes:

...

Hi,

Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner:

...
nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3... and will try with these.

Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4.

and the build went further, I now have

snip

...

Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951

Ben, can you help me out here?

I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie. Unfortunately every subsequent build seems to fail with this build system issue, ... "inplace/bin/ghc-cabal" configure libraries/integer-gmp dist-install "" --with-ghc="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1" --with-ghc-pkg="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh c-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=L DFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" -- with-ranlib="/usr/bin/ranlib" --with-alex="/home/ben/.cabal/bin/alex" --with-happy="/home/ben/.cabal/bin/happy" Configuring integer-gmp-0.5.1.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: error: cannot run /bin/bash ./config.sub libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however. Have you seen this in the past? Cheers, - Ben

Joachim Breitner

3:49 p.m.

Hi, Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari:

...

...
Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951

Ben, can you help me out here?

I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie.

Weird. Can you try creating a sid chroot and building it in there? I managed to finish the build with this patch attached: Index: ghc-7.8.20141119/includes/stg/SMP.h =================================================================== --- ghc-7.8.20141119.orig/includes/stg/SMP.h +++ ghc-7.8.20141119/includes/stg/SMP.h @@ -14,13 +14,13 @@ #ifndef SMP_H #define SMP_H -#if defined(THREADED_RTS) - #if arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) void arm_atomic_spin_lock(void); void arm_atomic_spin_unlock(void); #endif +#if defined(THREADED_RTS) + /* ---------------------------------------------------------------------------- Atomic operations ------------------------------------------------------------------------- */ Index: ghc-7.8.20141119/rts/OldARMAtomic.c =================================================================== --- ghc-7.8.20141119.orig/rts/OldARMAtomic.c +++ ghc-7.8.20141119/rts/OldARMAtomic.c @@ -14,8 +14,6 @@ #include #endif -#if defined(THREADED_RTS) - #if arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) static volatile int atomic_spin = 0; @@ -51,6 +49,3 @@ void arm_atomic_spin_unlock() } #endif /* arm_HOST_ARCH && defined(arm_HOST_ARCH_PRE_ARMv6) */ - -#endif /* defined(THREADED_RTS) */ - So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not?

...

Unfortunately every subsequent build seems to fail with this build system issue,

... "inplace/bin/ghc-cabal" configure libraries/integer-gmp dist-install "" --with-ghc="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1" --with-ghc-pkg="/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh c-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=L DFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" -- with-ranlib="/usr/bin/ranlib" --with-alex="/home/ben/.cabal/bin/alex" --with-happy="/home/ben/.cabal/bin/happy" Configuring integer-gmp-0.5.1.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: error: cannot run /bin/bash ./config.sub libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed

It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however.

Have you seen this in the past?

Yes, likely a bug in dh_autoreconf that does not handle rebuilds well (or a bug in how we use it). Until that is fixed I use rm -rf ghc-7.8.20141119 && dpkg-source -x ghc_7.8.20141119-6.dsc && cd ghc-7.8.20141119/ && schroot -r -c ghc -- debuild -uc -us to get a clean state again. I’ll have to look into that eventually. Autoconf is a mess. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Karel Gardas

4:34 p.m.

On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

...

So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not?

Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Hope that helps, Karel [1]: https://wiki.debian.org/ArmEabiPort [2]: https://wiki.debian.org/ArmHardFloatPort

Joachim Breitner

4:44 p.m.

Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas:

...

On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

...
So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not?

Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1].

I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there

...

I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware...

Yes, that makes sense. In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Karel Gardas

5:06 p.m.

On 12/ 8/14 04:44 PM, Joachim Breitner wrote:

...

Hi,

Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas:

...
On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

...
So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not?

Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1].

I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there

Yes, but [2] is what Ubuntu is using and it was all right in the past at least modulo ghci/linker support which Ben was fixing.

...

...
I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware...

Yes, that makes sense.

In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right?

Yes, probably, I've not followed whole thread of discussion unfortunately. BTW, IIRC this is configure/aclocal.m4 check what's the target ARM platrform capability, I'm a little bit surprised this is not working for you now. Also please make sure generated platform details are correct in settings file... Karel

Ben Gamari

5:43 p.m.

Joachim Breitner writes:

...

Hi,

Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas:

...
On 12/ 8/14 03:49 PM, Joachim Breitner wrote:

...
So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not?

Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1].

I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there

Indeed I think Karel has identified the difference in that case. I'm on armhf. Thanks Karel! I didn't realize that armel supported such old hardware.

...

...
I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware...

Yes, that makes sense.

In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right?

Indeed. It seems that armel is indeed supposed to support down to ARMv5 for which we'll need the spinlock fallback. Cheers, - Ben

Joachim Breitner

9 Dec 9 Dec

11:06 a.m.

New subject: The GHC 7.8.4 debian package now builds on arm

[Fixing the subject, it hasn’t been about LLVM for a while] Hi, with the help of Ben I managed to create a GHC 7.8.4-rc1 Debian package that builds on arm and armhf. I had to apply a few patches from GHC HEAD, which I hope can enter 7.8.4. (I’ve marked their tickets as "merge" in trac.) Additionally, I had to fix something related to the pre-ARMv6 spinlock implementation: https://phabricator.haskell.org/D564 Finally, I had to find a reliable way to make ghc (and only ghc!) pass the flags to gcc to make it use the gold linker, but I don’t know if my approach is sensible. See http://ghc.haskell.org/trac/ghc/ticket/9873 I have a patch that seems to work here: https://ghc.haskell.org/trac/ghc/attachment/ticket/9873/saner-linker-opt-han... but I’d rather avoid using non-blessed patches in the Debian package. If using the gold linker is a requirement on armel, maybe that should also be handled in upstream? The patch is rather simple: Index: ghc-7.8.3.20141119/aclocal.m4 =================================================================== --- ghc-7.8.3.20141119.orig/aclocal.m4 2014-12-08 18:49:28.207171714 +0100 +++ ghc-7.8.3.20141119/aclocal.m4 2014-12-08 19:03:06.815522917 +0100 @@ -553,6 +553,10 @@ $3="$$3 -D_HPUX_SOURCE" $5="$$5 -D_HPUX_SOURCE" ;; + arm*) + # On arm, link using gold + $3="$$3 -fuse-ld=gold" + ;; esac # If gcc knows about the stack protector, turn it off. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

22 Dec 22 Dec

3:38 p.m.

New subject: The GHC 7.8.4 debian package now builds on arm

Hi Ben, it seems the story is not over yet. For some reason, building out-of-tree libraries (like mtl) does not build .so files on arm*: https://buildd.debian.org/status/fetch.php?pkg=haskell-mtl&arch=armhf&ver=2.1.3.1-1&stamp=1418087332 which later causes breakage: [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.o ) [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.p_o ) https://buildd.debian.org/status/fetch.php?pkg=haskell-binary-shared&arch=armhf&ver=0.8.3-2&stamp=1419258130 Do you have any rough guesses what might be causing this? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner

4:45 p.m.

New subject: The GHC 7.8.4 debian package now builds on arm

Hi, Am Montag, den 22.12.2014, 15:38 +0100 schrieb Joachim Breitner:

...

it seems the story is not over yet. For some reason, building out-of-tree libraries (like mtl) does not build .so files on arm*:

https://buildd.debian.org/status/fetch.php?pkg=haskell-mtl&arch=armhf&ver=2.1.3.1-1&stamp=1418087332

which later causes breakage: [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.o ) [1 of 1] Compiling Data.Binary.Shared ( src/Data/Binary/Shared.hs, dist-ghc/build/Data/Binary/Shared.p_o ) https://buildd.debian.org/status/fetch.php?pkg=haskell-binary-shared&arch=armhf&ver=0.8.3-2&stamp=1419258130

Do you have any rough guesses what might be causing this?

nevermind. I guess I built that with a previous upload of GHC that still had ghc on the NoSharedLibsPlatformList. A rebuild should fix that. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Erik de Castro Lopo

27 Dec 27 Dec

9:28 a.m.

Ben Gamari wrote:

...

I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance.

To summarize,

* it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal

* ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged

* I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12

* Austin's LLVM packaging proposal seems very much like the right way forward

* Anticipating this proposal, I have started collecting [2] optimization passes

I've recently been working on amd64-linux to armhf-linux and aarch64-linux cross-compilers. In addition to the above: * LLVM 3.6 that Ben mentions above has not yet been released and is still a work in progress. A commit to the LLVM tree made as recently as December 17th means LLVM head no longer compiles LLVM IR code generated by GHC (metadata issue mentioned in #9920). * LLVM uses C/C++ asserts liberally and these asserts get compiled out during optimised builds (eg for Linux distributions). The removal of these asserts results in llvm binaries that *silently* generate incorrect binaries (see #9920 which is Ben's second bullet point above). For instance, I built an amd64-linux to aarch64-linux cross compiler which generated executables that crashed immediately. When I switched to a debug version of LLVM, LLVM's opt and llc suddenly started showing assertion failures all over. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4020

Age (days ago)

4049

Last active (days ago)

List overview

Download

25 comments

4 participants

participants (4)

Ben Gamari
Erik de Castro Lopo
Joachim Breitner
Karel Gardas

Status and future of the LLVM backend

tags

participants (4)