OSDev.org

Hi,

I'm having a bit of trouble with GCC. If I declare a static global variable in a source file, objdump -h shows the size of the variable reflected in the size of the .bss segment in the object (.o) file. If I declare a non-static global variable, the size is not shown in the .bss segment. Where are non-static global variables allocated/reserved in the object file?

Thanks,

onlyonemac

They are saved in the .data section where all your data (read, write) is saved.

This article can help.

Could you check 'objdump -t' to find out the section where the non-static global resides?

Ch4ozz wrote:They are saved in the .data section where all your data (read, write) is saved.

The size of .data doesn't change when I make the variable non-static; only the size of .bss decreases by the size of the variable.

linuxyne wrote:This article can help.

Could you check 'objdump -t' to find out the section where the non-static global resides?

If it's static then it says .bss; if it's non-static then it says *COM*. Reading the linked article I see what this means, although I'm not sure how to integrate that into my linkscript.

onlyonemac wrote:

Ch4ozz wrote:They are saved in the .data section where all your data (read, write) is saved.

The size of .data doesn't change when I make the variable non-static; only the size of .bss decreases by the size of the variable.

linuxyne wrote:This article can help.

Could you check 'objdump -t' to find out the section where the non-static global resides?

If it's static then it says .bss; if it's non-static then it says *COM*. Reading the linked article I see what this means, although I'm not sure how to integrate that into my linkscript.

Of course it doesnt change, all other sections then .bss are aligned

onlyonemac wrote:I'm not sure how to integrate that into my linkscript.

* The symbol will end up in .bss, if it is uninitialised everywhere.
* Or, use fno-common for immediate certainty within .o files.

linuxyne wrote:* The symbol will end up in .bss, if it is uninitialised everywhere.

Except it doesn't, unless it's declared static.

Oh, and I'm also having trouble with my linkscript where .bss doesn't seem to be copied to the final binary.

I should have been more clear about my statements.
The non-static global symbol will end up in .bss section of the executable, if it is uninitialised in all .o files that define that symbol. This should not be very difficult to test and verify.

onlyonemac wrote:Oh, and I'm also having trouble with my linkscript where .bss doesn't seem to be copied to the final binary.

Are you saying there isn't even a section header referencing the .bss section? You shouldn't expect any more in the executable.

Never mind I now have both static and non-static globals in their correct places in the final linked binary.

linuxyne wrote:The non-static global symbol will end up in .bss section of the executable, if it is uninitialised in all .o files that define that symbol. This should not be very difficult to test and verify.

It's a flat binary, so no chance of checking sections here. The size wasn't changing when I added the non-static global, but it is now as it should be.

iansjack wrote:

onlyonemac wrote:Oh, and I'm also having trouble with my linkscript where .bss doesn't seem to be copied to the final binary.

Are you saying there isn't even a section header referencing the .bss section? You shouldn't expect any more in the executable.

Again, it's a flat binary so there are no section headers. I was expecting it to actually reserve the space for the .bss section in the binary since it was outputting a flat binary, but it seems it didn't (until now ).

For reference, the COMMON section (what you saw labeled as *COM*) serves the same purpose as .bss and can be included in the linker script the same way (something like (*(.bss COMMON)") or bypassed with -fno-common as mentioned earlier.

Ch4ozz wrote:They are saved in the .data section where all your data (read, write) is saved.

If only it were so.
Uninitialized variables or variables assigned as zero will end up in the .bss. Of course the .bss is technically data, however when creating flat
binaries if the loader (without the aid of a non existent header) doesn't initialize the .bss to zero you may not get the expected zero value.

mikegonta wrote:

Ch4ozz wrote:They are saved in the .data section where all your data (read, write) is saved.

If only it were so.
Uninitialized variables or variables assigned as zero will end up in the .bss. Of course the .bss is technically data, however when creating flat
binaries if the loader (without the aid of a non existent header) doesn't initialize the .bss to zero you may not get the expected zero value.

Compile it with -fno-zero-initialized-in-bss

mikegonta wrote:

Ch4ozz wrote:They are saved in the .data section where all your data (read, write) is saved.

If only it were so.
Uninitialized variables or variables assigned as zero will end up in the .bss. Of course the .bss is technically data, however when creating flat
binaries if the loader (without the aid of a non existent header) doesn't initialize the .bss to zero you may not get the expected zero value.

That's not a problem for me as I'm initialising everything myself. I never assume that an uninitialised value contains zero.

onlyonemac wrote:That's not a problem for me as I'm initialising everything myself. I never assume that an uninitialised value contains zero.

Sounds very dangerous because there are problems with the magic number zero. If you take a random memory location, it is very likely that it may just be zero. I can sense that this will cause you problems in the future, e.g. random bugs on conditions other than you used when testing your code. Another problem is compiler assumptions. Your explicit value initialisation may be optimized away if it is redundant.