enormous executable

Ken Shan ken@digitas.harvard.edu
Tue, 2 Oct 2001 21:54:32 -0400

Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2001-10-03T10:37:24+1000, Manuel M. T. Chakravarty wrote:
> "Simon Marlow" <simonmar@microsoft.com> wrote,
> > > | Surely the executable itself is only linked with the=20
> > > | functions that are actually used by the program? =20
> > > AFAIUI the GNU linker is not clever enough to remove junk
> > > on a per-function basis, only on a per-object basis.  This is
> > > why we do object-splitting -- by breaking libraries up into=20
> > > thousands of .o files before rolling them into a .a, the
> > > effectiveness of what GNU ld can do is enhanced.
> > > Perhaps more recent GNU ld's do better on some platforms?
> > > I have a vague recollection of some -gc-sections flag.
> > Yup, but it needs compiler support.  The idea is to get the compiler to
> > put each function in its own section, then the linker removes unused
> > sections from the linked image.
> Sounds much better than the mess that -split-objs produces
> on the harddisk.

I don't think the native ld on alpha-dec-osf3 supports such a feature,
so we would (I assume) have to leave -split-objs in ghc even if we do
implement -ffunction-sections/-fdata-sections.  (Would it just be a
matter of enabling it when invoking gcc?  Would I be able to try it on
my i386-linux box with -optc-ffunction-sections?  Or I suppose the
mangler would need to be educated...)

Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org