Symbols which were not used, still in binary

Symbols which were not used, still in binary

[Steve Kreyer]

Hi,

I have a question about an optimization issue.

I have compiled the follwing code with the command ''gcc file.c''

---------------------------------------------------------------
int add(int a, int b){
    return a + b;
}

int main(){
}
--------------------------------------------------------------

My question is:
Why does the symbol "add" appear in the outcoming binary file?
nm gives me:
--------------------------------------------------------------
redwing@euklid:~ $ nm a.out | grep add
08048324 T add
--------------------------------------------------------------

Neither is it used in this piece of code, nor is it compiled into an 
object file,
so in my opinion it should be optimized away by gcc.
So perhaps anybody can tell me whats wrong with my thought...

Thanks in advance.

Steve

P.S. If this is not the right mailing list for this question, let me know :)

Re: Symbols which were not used, still in binary

[Brian Dessent]

Steve Kreyer wrote:

> I have compiled the follwing code with the command ''gcc file.c''
>
> ...
> 
> Neither is it used in this piece of code, nor is it compiled into an
> object file,
> so in my opinion it should be optimized away by gcc.
> So perhaps anybody can tell me whats wrong with my thought...

First of all, if you just type "gcc file.c" then you have not enabled
any optimization at all.  You have to supply -O2 (or -Os, -O1, etc.) if
you want the compiler to perform optimization, as the default is -O0.

That aside, the function won't be eliminated until it's declared
"static", as some other module could still call it.

Brian

Re: Symbols which were not used, still in binary

[Michael Eager]

Steve Kreyer wrote:
> Hi,
> 
> I have a question about an optimization issue.
> 
> I have compiled the follwing code with the command ''gcc file.c''
> 
> ---------------------------------------------------------------
> int add(int a, int b){
>    return a + b;
> }
> 
> int main(){
> }
> --------------------------------------------------------------
> 
> My question is:
> Why does the symbol "add" appear in the outcoming binary file?
> nm gives me:
> --------------------------------------------------------------
> redwing@euklid:~ $ nm a.out | grep add
> 08048324 T add
> --------------------------------------------------------------
> 
> Neither is it used in this piece of code, nor is it compiled into an 
> object file,
> so in my opinion it should be optimized away by gcc.
> So perhaps anybody can tell me whats wrong with my thought...

add is a global symbol.  GCC has no way of knowing whether or not
this object file will be linked with another file which contains
a reference to the function.  Arguably, the linker should know
that add is not referenced and could remove it, but linkers are not
usually able to slice and dice object files.

[If you declare add to be static, then GCC should be able
to eliminate it.  But it doesn't.]

Programs often contain functions which are designed
to be called by someone using a debugger but are otherwise
not referenced.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Symbols which were not used, still in binary

[Brian Dessent]

Michael Eager wrote:

> Arguably, the linker should know
> that add is not referenced and could remove it, but linkers are not
> usually able to slice and dice object files.

You address this limitation by compiling with "-ffunction-sections
-fdata-sections -Wl,--gc-sections".  However, it's still better to use
"static" on these kinds of local functions that are only used from the
same .o file.  This has a number of benefits:

- it ensures that internal functions of a library are not exported for
use by other code when they are not part of the defined ABI/API
- it prevents them from taking up needless relocations, which can slow
linking
- when compiled -fpic (as in a shared library) it allows for direct
calls to the function instead of having to go through the PLT which is
slower
- it allows the compiler freedom to inline

Brian

Re: Symbols which were not used, still in binary

[Steve Kreyer]

Hello Brain, hi Michael,

your arguments sound plausible to me,
also I wasn't really aware about the function context of "static".

Thanks for the clarification!

Regards,

Steve

Re: Symbols which were not used, still in binary

[Ingo Krabbe]

Am Mittwoch, 28. Juni 2006 23:20 schrieb Brian Dessent:
> Michael Eager wrote:
> > Arguably, the linker should know
> > that add is not referenced and could remove it, but linkers are not
> > usually able to slice and dice object files.
>
> You address this limitation by compiling with "-ffunction-sections
> -fdata-sections -Wl,--gc-sections".  However, it's still better to use
> "static" on these kinds of local functions that are only used from the
> same .o file.  This has a number of benefits:
>
> - it ensures that internal functions of a library are not exported for
> use by other code when they are not part of the defined ABI/API
> - it prevents them from taking up needless relocations, which can slow
> linking
> - when compiled -fpic (as in a shared library) it allows for direct
> calls to the function instead of having to go through the PLT which is
> slower
> - it allows the compiler freedom to inline
>

and you are warned about unused static symbols.  hmm, reminds me of cleaning 
my attic ...

> Brian