help GNU ld to use less memory when linking libraries compiled with -split-objs.

[int-e]

This is a well-known problem, but I didn't find a previous report here, probably because it is mainly a GNU ld issue. The problem is that with -split-objs, linking, say, ghc, takes a trememndous amount of memory.

Part of this problem will be fixed in ld:

 http://sourceware.org/bugzilla/show_bug.cgi?id=12682

In this bug report, Nick Clifton suggests to use '--hash-size=31' and possibly '--reduce-memory-overhead' when invoking ld. Since ghc is invoking gcc for linking, that would mean passing '-Xlinker --hash-size=31' and perhaps '-Xlinker --reduce-memory-overhead' to gcc.

Can we do that? Care needs to be taken if people use the -pgmL option, and we should make sure that gcc is actually using GNU ld.

In my experiments (linking ghc), --hash-size=31 helps, reducing memory usage by about a factor of 1/2; --reduce-memory-overhead without --hash-size=31 also helps (saving about 1/3), but has no noticable effect in connection with --hash-size=31. Based on that I'd suggest to only use --hash-size=31.

[igloo@…]

commit 3275b7bd2a803a3adc0b952b6fbfeb738fc15a74

Author: Ian Lynagh <igloo@earth.li>
Date:   Sun Nov 27 00:20:59 2011 +0000

    Pass "--hash-size=31 --reduce-memory-overhead" to ld; fixes trac #5240
    
    These reduce the amount of memory that ld takes when linking.

 aclocal.m4                 |    9 +++++++--
 rules/build-package-way.mk |    2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

[igloo]

Fixed.

[pgj]

The fix works nicely, however it generates a lot of warnings when linking is not done, which is very annoying. So I created a patch to correct this.

[igloo]

pgj, I'm not sure what you mean by "it generates a lot of warnings when linking is not done". I've tried a few things, but failed to get it to produce any warnings.

Can you give some example commands showing how to create the warnings please?

[pgj]

Replying to igloo:

Can you give some example commands showing how to create the warnings please?

Sorry, it seems I forgot to add that these warnings appear only on FreeBSD 9.0 or later. It is because that there were some changes or updates in the base system toolchain, which make the linker very sensitive about unused flags.

So the best way to reproduce them is to get a working FreeBSD 9 installation (in a virtual machine, for example) and try to build the vanilla GHC sources. Then one should see a lot of messages like this:

gcc: --hash-size=31: linker input file unused because linking not done
gcc: --reduce-memory-overheads: linker input file unused because linking not done

(Such messages tripled the size of the log.) Perhaps this would be fine, but since such flags are also recorded in the "settings" file, the compilation of every Haskell source file will generate the same messages on FreeBSD 9.0 or later.

Note that the builder clients will not yet generate warnings as they are at 8.1, the oldest supported release currently (where the linker does not support the requested features).

[igloo]

Does this happen if you run:

echo "int f(int x) { return x; }" > j.c
ghc -c j.c

? If so, can you copy/paste the output of

ghc -c j.c -v

please?

[pgj]

Replying to igloo:

Does this happen if you run ..?

No, it does not happen. But let me note that it is because the "settings" file does not contain the "--hash-size=31" and "--reduce-memory-overheads" flags for the linker.

When looking deeper into the cause, it turns out that when configuring the vanilla ghc bindist (7.4.2, built from sources on FreeBSD/amd64 -CURRENT) for installation, all those linker flag tests fail, because LdCmd has no value! (That is, the configure script gives different results for linker flag tests when building the compiler and when installing it!)

However, when I use the "settings" file right from the directory where the compiler was originally built and the information on linker flags is not lost (the same happens when installing the corresponding port):

> ghc -c j.c
gcc: --hash-size=31: linker input file unused because linking not done
gcc: --reduce-memory-overheads: linker input file unused because linking not done
gcc: --hash-size=31: linker input file unused because linking not done
gcc: --reduce-memory-overheads: linker input file unused because linking not done

Is this intentional...?

[igloo]

Can you show me the output with -v please? And can you also clarify whether your ld supports those flags please?

[pgj]

Replying to igloo:

Can you show me the output with -v please?

Sure. Here it is:

> /usr/local/ghc-7.4.2/bin/ghc -v -c j.c
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.4
Using binary package database: /usr/local/ghc-7.4.2/lib/ghc-7.4.2/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-7d3c2c69a5e8257a04b2c679c40e2fa7
wired-in package integer-gmp mapped to integer-gmp-0.4.0.0-af3a28fdc4138858e0c7c5ecc2a64f43
wired-in package base mapped to base-4.5.1.0-ac318071cf9dcba0758e9123955468c5
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.7.0.0-d08d077053eac454ce08e17f2c95c5c8
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
Created temporary directory: /tmp/ghc33022_0
*** C Compiler:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-x' 'c' 'j.c' '-o' '/tmp/ghc33022_0/ghc33022_0.s' '-S' '-Wimplicit' '-O' '-D__GLASGOW_HASKELL__=704' '-DTABLES_NEXT_TO_CODE' '-I' '/usr/local/include' '-I' '/usr/local/ghc-7.4.2/lib/ghc-7.4.2/base-4.5.1.0/include' '-I' '/usr/local/ghc-7.4.2/lib/ghc-7.4.2/include'
gcc: --hash-size=31: linker input file unused because linking not done
gcc: --reduce-memory-overheads: linker input file unused because linking not done
*** Assembler:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-c' '/tmp/ghc33022_0/ghc33022_0.s' '-o' 'j.o'
gcc: --hash-size=31: linker input file unused because linking not done
gcc: --reduce-memory-overheads: linker input file unused because linking not done
*** Deleting temp files:
Deleting: /tmp/ghc33022_0/ghc33022_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc33022_0

And can you also clarify whether your ld supports those flags please?

Well, perhaps the version numbers can tell, but I looked it up in the manual page, and ld(1) definitely support these flags.

So:

> ld -v
GNU ld 2.17.50 [FreeBSD] 2007-07-03

> ld --help | grep -E "(hash-size|reduce)"
  --hash-size=<NUMBER>        Set default hash table size close to <NUMBER>
  --reduce-memory-overheads   Reduce memory overheads, possibly taking much longer

[igloo]

Hmm. What does

/usr/bin/gcc --version

say?

[pgj]

Replying to igloo:

> /usr/bin/gcc --version
gcc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[igloo]

Aha, looks like this is an old gcc bug that has been fixed:

$ /usr/bin/gcc-4.1 -c j.c -Wl,--foo
gcc-4.1: --foo: linker input file unused because linking not done
$ /usr/bin/gcc-4.3 -c j.c -Wl,--foo
$ 

I don't think it's worth working around this in GHC, as (a) it doesn't cause any real problems, just prints some warnings, and (b) it can be solved by upgrading to a recent gcc.

I have just pushed a patch to fix the problem that LdCmd wasn't getting defined in the bindist configure.ac, though. Thanks for spotting that.

[pgj]

Replying to igloo:

I don't think it's worth working around this in GHC

I think this is not a workaround as the linker flags should not indeed passed when no linking is done. I do not think that the warning is bogus. It is just a more fine-grained way to pass the flags only when they are really needed.

(a) it doesn't cause any real problems, just prints some warnings

...for every Haskell module, which -- as I wrote above -- triples the number of the messages printed to the screen. I do not think that it is good to see such messages all the time.

(b) it can be solved by upgrading to a recent gcc.

It is not by accident that the FreeBSD base system does not have a more recent GCC, folks here are moving to a Clang/LLVM instead. Of course, I could use a newer GCC by adding it as a dependency for the port, but I was trying to avoid this.

Anyways, since GCC is going to be removed from the base system in the next major release, I shall switch to this solution soon... :-)

I have just pushed a patch to fix the problem that LdCmd wasn't getting defined in the bindist configure.ac, though. Thanks for spotting that.

Great, thanks!