--gc-sections on x86

--gc-sections on x86

[Gabriel Linder]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Hi list,

I am trying to remove some unused functions from our programs, with gcc 
flag -ffunction-sections and ld flag --gc-sections, but it doesn't seem 
to work at all :-(

I use gcc 3.2.2, and I get the following (sample source attached, 18 
lines) :
2828 bytes with gcc -march=i686 -O2 -ffunction-sections 
-Wl,--gc-sections oblivion.c -o oblivion && strip -s oblivion
2812 bytes with gcc -DNOTHING -march=i686 -O2 -ffunction-sections 
-Wl,--gc-sections oblivion.c -o oblivion && strip -s oblivion

Is this a known problem ? Is a workaround available ?

[-- Attachment #2: oblivion.c --]
[-- Type: text/plain, Size: 234 bytes --]

#include <stdio.h>

#ifndef NOTHING
int nothing(int n) // unused function, should not be in binary !
{
	return n;
}
#endif

int hello(void) // used function
{
	return printf("I do nothing !\n");
}

int main(void)
{
	return hello();
}

Re: --gc-sections on x86

[Brian Dessent]

Gabriel Linder wrote:

> I am trying to remove some unused functions from our programs, with gcc
> flag -ffunction-sections and ld flag --gc-sections, but it doesn't seem
> to work at all :-(
> 
> I use gcc 3.2.2, and I get the following (sample source attached, 18
> lines) :
> 2828 bytes with gcc -march=i686 -O2 -ffunction-sections
> -Wl,--gc-sections oblivion.c -o oblivion && strip -s oblivion
> 2812 bytes with gcc -DNOTHING -march=i686 -O2 -ffunction-sections
> -Wl,--gc-sections oblivion.c -o oblivion && strip -s oblivion
> 
> Is this a known problem ? Is a workaround available ?

This testcase may not be actually showing you what you want.  You have
to balance the extra overhead of having a section for each function
against the savings, and in this case the function being removed is
completely trivial.  When you're looking at a 2800 byte ELF file the
noise (headers, padding, etc) is going to overwhelm everything.  Try a
more realistic testcase.

Brian

Re: --gc-sections on x86

[Gabriel Linder]

Brian Dessent wrote:
> This testcase may not be actually showing you what you want.  You have
> to balance the extra overhead of having a section for each function
> against the savings, and in this case the function being removed is
> completely trivial.  When you're looking at a 2800 byte ELF file the
> noise (headers, padding, etc) is going to overwhelm everything.  Try a
> more realistic testcase.
Well, that was a trivial testcase, as you said. In real life I have a 
lot of .c files with generic functions, but not all of them are used by 
all binaries I build. So I search for a way to clean out unused 
functions between modules, if possible.

The --gc-sections trick was found after some search, I found also a "set 
inline function size to 0 and enable inlining" hint (on RedHat lists, if 
I remember correctly) but none of them works.

Re: --gc-sections on x86

[John Love-Jensen]

Hi Gabriel,

Don't go by size, especially for such a trivial test case.

Use the nm command to confirm that the nothing() routine is no longer in
your first test case.

HTH,
--Eljay

Re: --gc-sections on x86

[Perry Smith]

On Dec 5, 2006, at 4:13 AM, Gabriel Linder wrote:

> Brian Dessent wrote:
>> This testcase may not be actually showing you what you want.  You  
>> have
>> to balance the extra overhead of having a section for each function
>> against the savings, and in this case the function being removed is
>> completely trivial.  When you're looking at a 2800 byte ELF file the
>> noise (headers, padding, etc) is going to overwhelm everything.   
>> Try a
>> more realistic testcase.
> Well, that was a trivial testcase, as you said. In real life I have  
> a lot of .c files with generic functions, but not all of them are  
> used by all binaries I build. So I search for a way to clean out  
> unused functions between modules, if possible.
>
> The --gc-sections trick was found after some search, I found also a  
> "set inline function size to 0 and enable inlining" hint (on RedHat  
> lists, if I remember correctly) but none of them works.

It seems like if you had to, you could analyze the output of nm of  
the object files -- maybe even the final compiled program.  nm will  
tell you where symbols are defined and reference.

Perry Smith ( pedz@easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems