I'm running a little test while trying to understand a larger problem. Here's my test env:
head.h:
#define MAX_BUFSIZE 500
typedef struct {
int head;
int tail;
int status;
int active;
void * dev[MAX_BUFSIZE];
char free[MAX_BUFSIZE];
int count;
} msg_fifo_t;
extern msg_fifo_t TxBufx[];
extern msg_fifo_t Rx_Buf[];
test.c:
#include <stdio.h>
#include "head.h"
//msg_fifo_t TxBufx[10]; // This is the important line
int main(int argc, char * argv[])
{
// This part isn't really important...
printf("Hello Test\n");
return 0;
}
So I used these files and ran three tests to see what sizes I got -
test #1 (code as is above):
> gcc -Os test.c
> ls -al a.out
-rwxrwxr-x 1 mike mike 7158 Jan 17 11:13 a.out
> size a.out
text data bss dec hex filename
1170 256 8 1434 59a a.out
test #2 (uncomment the "important" line):
> gcc -Os test.c
> ls -al a.out
-rwxrwxr-x 1 mike mike 7181 Jan 17 11:14 a.out
> size a.out
text data bss dec hex filename
1170 256 25208 26634 680a a.out
test #3 (uncomment the "important" line and change TxBufx
size to 100)
> gcc -Os test.c
> ls -al a.out
-rwxrwxr-x 1 mike mike 7181 Jan 17 11:14 a.out
> size a.out
text data bss dec hex filename
1170 256 252008 253434 3ddfa a.out
So now my questions:
It would appear that bss size has almost no bearing on the "size" of an executable (as reported from the ls -al
command) - Can anyone explain to me why that is?
Is that trait specific to the compiler/linker/or platform?
Is there a better tool than size
to understand what is happening here? (meaning what is really making up the 7181 bytes that is my executable?)
The amount of data in the bss
segment has no effect on the size on disk of your executable because of what the bss
segment is -- this is the section of your program used for variables initialized to zero. Since the content of this section is known in advance (all zeroes), the only thing actually stored in the executable file is the size of this region.
So the things that do change as your code changes are the size of the data
segment -- representing variables statically initialized to non-zero values, and the size of the code
segment, representing the compiled executable instructions corresponding to your program.
As for tools to use, the objdump(1) utility on most Unix systems (it's part of the GNU toolchain) or the otool(1) utility on MacOS X can both be used to get more detailed information about what sections make up your executable, and what symbols are in each one.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With