Linker question about global vs. local symbols

Linker question about global vs. local symbols

[Dave Gotwisner]

I have a C++ embedded application which has a TON of symbols.  Because
of the way the target must be built, our link phase takes about 20
minutes on a Sun.  Several thousand of the symbols are currently global
but can be made local, because they are only used from the one source
file that contains them.  When developing and fixing bugs, we may do
compile / link cycles many times in a day. 

From what I understand, all symbols (both local and global) always
appear in the symbol table for the GNU tool chain.  (Older compilers I
worked with didn't expose any local symbols outside of the .o). 

Would link times get reduced by making a large % of the symbols that are
currently global into local (ie, static) symbols?  Does the linker do a
filtering pass that walks all the objects and libraries in question to
build a list of global symbols that it later works on rather than always
trying to resolve each symbol off the full list? 

Splitting the app into smaller executables isn't possible because of the
architecture and cross dependencies. 

Any info anyone can give would be appreciated. 

Thanks,
	Dave

Re: Linker question about global vs. local symbols

[Ian Lance Taylor]

"Dave Gotwisner" <Dave.Gotwisner@harmonicinc.com> writes:

> I have a C++ embedded application which has a TON of symbols.  Because
> of the way the target must be built, our link phase takes about 20
> minutes on a Sun.  Several thousand of the symbols are currently global
> but can be made local, because they are only used from the one source
> file that contains them.  When developing and fixing bugs, we may do
> compile / link cycles many times in a day. 
> 
> From what I understand, all symbols (both local and global) always
> appear in the symbol table for the GNU tool chain.  (Older compilers I
> worked with didn't expose any local symbols outside of the .o). 
> 
> Would link times get reduced by making a large % of the symbols that are
> currently global into local (ie, static) symbols?  Does the linker do a
> filtering pass that walks all the objects and libraries in question to
> build a list of global symbols that it later works on rather than always
> trying to resolve each symbol off the full list? 
> 
> Splitting the app into smaller executables isn't possible because of the
> architecture and cross dependencies. 

Linker questions are probably better directed to
binutils@sourceware.org.  See http://sourceware.org/binutils/.

The linker does walk through every .o file and gathers all the global
symbols into a hash table.  It then decides where to place the input
sections in the output file.  It then walks through every .o file
again and computes the relocations and does the final link.

When walking through .o files the linker generally ignores the local
symbols.  The local symbols are only examined if there are any
relocations which reference them.

It is likely that reducing the number of global symbols will speed up
the link.  It is unlikely to speed it up very much.  I recommend
building a profiling version of the linker to see where the time is
actually being taken.  And make sure you are using the latest version,
as the linker normally gets a little bit faster with each new release.

Ian