GCC overhead?
Posted: Fri Jan 16, 2009 9:43 am
Hello all, I have been an assembly programmer for some time.. however I want to try out gcc.. mainly for its optimizations and understandable code. Recently I posted, and found that apparently there are no assemblers that can optimize code in the way that gcc can.
I am trying to test out how small gcc can make code.. In order to do that I have made the following sample code:
As you can see, this code it extremely simple. "_start" is used directly by the linker and __asm__ should be directly compiled, so this code requires no libraries at all.
In assembly, this code in binary would only take up 1 byte. In order to avoid problems with symbolic information, I am trying to compile this code into raw binary.
So far, I tried compiling it with this:
nostdlib and nodefaultlibs removes any libraries that gcc loves to attach.
Os optimizes for size.
fomit-frame-pointer removes frame pointers from all functions if they are not needed.
finline-functions tries to optimize functions as if they were macros, if possible.
fdata-sections provides extra information to the linker so that the linker can later remove any extra useless data later.
ffunction-sections provides extra information to the linker so that the linker can later remove any extra useless functions later.
Ttext sets the starting area for code, Tdata sets the starting area for data.
gc-sections removes all useless data provided by fdata-sections and ffunction-sections.
s strips any remaining symbolic information.
Well apparently I'm missing something because the result is a binary file with the size of 4304 bytes..... I don't know why....
And here is the interesting part:
You can get gcc to use ld automatically.. You can pass some types of information to the linker through "-Wl," ...I tried that:
....and I got 715 bytes!
I am guessing that the reason behind this is because of either gcc sending extra information to the linker with the second method,
or
I am incorrectly using the first method as gcc is creating an executable and afterwards I try to "link" the executable.
I would really like someone to tell me what I am doing wrong. I originally left for assembly because I didn't understand what is this additional overhead, and I couldn't get rid of it. If I can get rid of most, if not all of the overhead, I will probably switch to programming in c.
Thank you,
Veniamin
I am trying to test out how small gcc can make code.. In order to do that I have made the following sample code:
Code: Select all
void _start()
{
__asm__("sti");
}
In assembly, this code in binary would only take up 1 byte. In order to avoid problems with symbolic information, I am trying to compile this code into raw binary.
So far, I tried compiling it with this:
Code: Select all
gcc -c test.c -o test.o -ansi -pedantic -Wall -Wextra -Werror -nostdlib -nodefaultlibs -Os -fomit-frame-pointer -finline-functions -fdata-sections -ffunction-sections
ld test.o -o test -Ttext 0 -Tdata 0 -Os --gc-sections -s
Os optimizes for size.
fomit-frame-pointer removes frame pointers from all functions if they are not needed.
finline-functions tries to optimize functions as if they were macros, if possible.
fdata-sections provides extra information to the linker so that the linker can later remove any extra useless data later.
ffunction-sections provides extra information to the linker so that the linker can later remove any extra useless functions later.
Ttext sets the starting area for code, Tdata sets the starting area for data.
gc-sections removes all useless data provided by fdata-sections and ffunction-sections.
s strips any remaining symbolic information.
Well apparently I'm missing something because the result is a binary file with the size of 4304 bytes..... I don't know why....
And here is the interesting part:
You can get gcc to use ld automatically.. You can pass some types of information to the linker through "-Wl," ...I tried that:
Code: Select all
gcc -c test.c -o test -ansi -pedantic -Wall -Wextra -Werror -nostdlib -nodefaultlibs -Os -fomit-frame-pointer -finline-functions -fdata-sections -ffunction-sections -Wl,-Os -Wl,--gc-sections -Wl,-s
I am guessing that the reason behind this is because of either gcc sending extra information to the linker with the second method,
or
I am incorrectly using the first method as gcc is creating an executable and afterwards I try to "link" the executable.
I would really like someone to tell me what I am doing wrong. I originally left for assembly because I didn't understand what is this additional overhead, and I couldn't get rid of it. If I can get rid of most, if not all of the overhead, I will probably switch to programming in c.
Thank you,
Veniamin