From mboxrd@z Thu Jan  1 00:00:00 1970
From: jtc@redback.com (J.T. Conklin)
To: binutils@sourceware.cygnus.com
Subject: linker memory footprint
Date: Mon, 04 Oct 1999 18:20:00 -0000
Message-id: <5miu4m7gf8.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-10/msg00005.html

During the final link of our firmware, the linker takes a huge amount
of memory (> ~240MB) to perform it's task.  Our typical desktop work-
station only has 128MB physical memory; so performance, in a single
word, sucks.  

Before sending the IT group out to buy SIMMs, I'm wondering if there
are any changes we can make to either the way our image is linked or a
linker memory reduction project I can sell management that I should be
working on.

Some details:

We link all of our modules into relocatable objects.  Those objects
are linked with our RTOS library, creating a much larger relocatable 
object, and finally that is linked with startup code and binary images
containing I/O card firmware.  Our intermediate relocatable object is
about 100MB.  The final image is 15MB with symbols, 5MB without.

Our software is built with both i386-aout and powerpc-eabi toolchains
with debugging (-g) enbabled.  The powerpc compiler emits BINCL/EINCL
stabs, which appears to require quite a bit of memory to process.  
But disabling BINCL/EINCL support only transfers the pain to GDB.

I've linked the linker with a memory-leak tracking library, ccmalloc,
and although there apear to be some leaks (~20MB, although I haven't
used ccmalloc enough to determine whether or not there are unreported
leaks or false matches), there are not enough to fully account for the
memory usage.

Short a project that keeps debug information in the object files and
modifies GDB to find it there, is there anything that can be done to
reduce ld's memory usage?

        --jtc

-- 
J.T. Conklin
RedBack Networks