Question

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?)

Answer 1

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.