linker memory footprint

linker memory footprint

[J.T. Conklin]

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

Re: linker memory footprint

[Ian Lance Taylor]

   From: jtc@redback.com (J.T. Conklin)
   Date: 04 Oct 1999 18:19:23 -0700

   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.

Are you using the --no-keep-memory option?

   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?

It would be possible to reduce ELF memory usage somewhat, and speed it
up somewhat, by adding an option to skip checking the relocations in
the first pass.  This would only be correct when not doing dynamic
linking, so it could not be the default.  Also, the --no-keep-memory
option would cause about the same amount of memory savings anyhow.

I don't know of any way to reduce memory usage of the a.out linker.

It's quite possible that there is some way to reduce memory usage, but
I just haven't thought of it.  It's also quite possible that there are
bugs.  I don't want to discourage you from investigating.

Ian

hppa1.1-rtems grepossible failure ?\x03

[Joel Sherrill]

I got this trying to compile:

gcc-2.95.1, newlib 1.8.2, and binutils 990901.  

touch stmp-headers
echo "void __foo () {}" > dummy.c
/usr1/rtems/work/tools/build-hppa1.1-tools/gcc/xgcc
-B/usr1/rtems/work/tools/build-hppa1.1-tools/gcc/
-B/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-rtems/hppa1.1-rtems/bin/
-I/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-rtems/hppa1.1-rtems/include
-DCROSS_COMPILE -DIN_GCC -DHAIFA    -O2 -g -I./include  -c dummy.c
/tmp/ccMjORtk.s: Assembler messages:
/tmp/ccMjORtk.s:2: Error: Unknown pseudo-op:  `.subspa'
/tmp/ccMjORtk.s:3: Error: Unknown pseudo-op:  `.subspa'
/tmp/ccMjORtk.s:5: Error: Unknown pseudo-op:  `.subspa'
/tmp/ccMjORtk.s:6: Error: Unknown pseudo-op:  `.subspa'
/tmp/ccMjORtk.s:14: Error: Unknown pseudo-op:  `.subspa'
/tmp/ccMjORtk.s:50: Error: Unknown pseudo-op:  `.subspa'

Any ideas?  In the RTEMS source, the hppa port uses .SUBSPA.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: hppa1.1-rtems grepossible failure ?

[Jeffrey A Law]

  In message < 37FA2EF7.1977EBE8@OARcorp.com >you write:
  > touch stmp-headers
  > echo "void __foo () {}" > dummy.c
  > /usr1/rtems/work/tools/build-hppa1.1-tools/gcc/xgcc
  > -B/usr1/rtems/work/tools/build-hppa1.1-tools/gcc/
  > -B/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-
  > rtems/hppa1.1-rtems/bin/
  > -I/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-
  > rtems/hppa1.1-rtems/include
  > -DCROSS_COMPILE -DIN_GCC -DHAIFA    -O2 -g -I./include  -c dummy.c
  > /tmp/ccMjORtk.s: Assembler messages:
  > /tmp/ccMjORtk.s:2: Error: Unknown pseudo-op:  `.subspa'
  > /tmp/ccMjORtk.s:3: Error: Unknown pseudo-op:  `.subspa'
  > /tmp/ccMjORtk.s:5: Error: Unknown pseudo-op:  `.subspa'
  > /tmp/ccMjORtk.s:6: Error: Unknown pseudo-op:  `.subspa'
  > /tmp/ccMjORtk.s:14: Error: Unknown pseudo-op:  `.subspa'
  > /tmp/ccMjORtk.s:50: Error: Unknown pseudo-op:  `.subspa'
  > 
  > Any ideas?  In the RTEMS source, the hppa port uses .SUBSPA.
The rtems port will need to be modified to not use .subspa.  .subspa
sectioning directives are not going to be supported for PA ELF targets
anymore.

jeff

Re: hppa1.1-rtems grepossible failure ?

[Joel Sherrill]

Jeffrey A Law wrote:
> 
>   In message < 37FA2EF7.1977EBE8@OARcorp.com >you write:
>   > touch stmp-headers
>   > echo "void __foo () {}" > dummy.c
>   > /usr1/rtems/work/tools/build-hppa1.1-tools/gcc/xgcc
>   > -B/usr1/rtems/work/tools/build-hppa1.1-tools/gcc/
>   > -B/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-
>   > rtems/hppa1.1-rtems/bin/
>   > -I/usr2/tools_install/gcc-2.95.1-binutils-990901-newlib-1.8.2-1099/hppa1.1-
>   > rtems/hppa1.1-rtems/include
>   > -DCROSS_COMPILE -DIN_GCC -DHAIFA    -O2 -g -I./include  -c dummy.c
>   > /tmp/ccMjORtk.s: Assembler messages:
>   > /tmp/ccMjORtk.s:2: Error: Unknown pseudo-op:  `.subspa'
>   > /tmp/ccMjORtk.s:3: Error: Unknown pseudo-op:  `.subspa'
>   > /tmp/ccMjORtk.s:5: Error: Unknown pseudo-op:  `.subspa'
>   > /tmp/ccMjORtk.s:6: Error: Unknown pseudo-op:  `.subspa'
>   > /tmp/ccMjORtk.s:14: Error: Unknown pseudo-op:  `.subspa'
>   > /tmp/ccMjORtk.s:50: Error: Unknown pseudo-op:  `.subspa'
>   >
>   > Any ideas?  In the RTEMS source, the hppa port uses .SUBSPA.
> The rtems port will need to be modified to not use .subspa.  .subspa
> sectioning directives are not going to be supported for PA ELF targets
> anymore.

It has been a long time since I messed with the hppa seriously.  Is
there a simple substitution that I can make?  I don't recall what
.subspa
actually did.  :(

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985