GCC440 (arm) : (.data) section is empty in output

Good day, I've noticed that the initialized data section in the program binary is zero bytes, by inspecting the file with 'size':

$ arm-none-eabi-size main.out text data bss dec hex filename 56160 0 2856 59016 e688 main.out

I'm running GCC 4.4.0, crosscompiled for ARM under Linux. I definately have the ".data" section in my linker script. The data section follows my (.text) section.

I've confirmed that I have some variables that are initialised inside my code where they are defined, i.e

---snip--- int main(void) { char myChar=5; ... }

Could somebody please give me some feedback on the way that GCC is handling initialized variables and if what I'm seeing is actually the correct behavior?

---snip--- .data 0x04000000 : AT (ADDR(.text) + SIZEOF(.text)) { . = ALIGN(4); datastart = .; __data_start__ = . ; *(.data) . = ALIGN(4); __data_end__ = . ; edata = .; _edata = .; }

---snip---

Regards, Frikkie Thirion

Reply to
frikkiethirion
Loading thread data ...

Since myChar is an automatic variable (declared within a function and without the "static" keyword), it is placed in the stack and not in a statically allocated memory location. The variable is initialized dynamically by code that is executed whenever "main" is entered and its stack frame is set up. Therefore I would not expect this variable to add anything to the "data" section.

--
Niklas Holsti
Tidorum Ltd
 Click to see the full signature
Reply to
Niklas Holsti

It is correct. Things were different when you would have declared myChar as being static. Only in this case the room occupied by char is permanent and can be statically initialized (i.e. at program starting time through .data).

Heike

Reply to
Heike C. Zimmerer

Good day, Thank you for the replies. I've done the following tests: 1) declared myChar static --> The size command now shows that .data occupies 4 bytes.

2) I've searched through the project and found a couple of other variables that are declared statically, but initialised as 0. The compiler/linker then decided not to add them to .data, but apparently to .bss.

As soon as I've changed some of them to be initialised to something other than 0, they appear in the .data section. Seems to be a good optimization, since the general practice for .bss (uninitialised data) is to clear it at startup time.

Reply to
frikkiethirion

That's not just "general practice" --- it's a requirement of the programming language. Some tools will let you turn that off (it could even happen by accident; BEWARE!), but by doing so you leave solid ground. Among other things, it opens up your program to bugs that hardly any code testing method in the world can help you discover, since they'll invariably assume that the tools behave like the language says they should.

Reply to
Hans-Bernhard Bröker

No it isn't. The C standard doesn't say anything about segments or executable formats.

Static variables lacking an explicit initialiser are implicitly initialised to zero (rather than containing garbage like uninitialised automatic variables), but this doesn't have to use the "bss optimisation"; the compiler is free to store all static variables in the same way, regardless of whether they are zero.

Reply to
Nobody

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.