CODEWITHSUNDEEP
cembedded
Sahil Vartak
Sahil Vartak

Reputation: 13

Can I map global variables to a section other than the .data or .bss sections?

What will happen if I do not map global variables in the .data or .bss section. When I try to map it in different section other than .bss and .data, it takes some garbage value.

Can we define other section for global variables other than .bss or .data?

Upvotes: 0

Views: 345

Answers (2)

old_timer
old_timer

Reputation: 71586

It depends on your compiler, it should be the one that marks that data as .bss or .data and then in your linker script you might not have a choice as to what section they are in, but you certainly have the choice as to where they go, and if you start messing with that you might have to mess with the bootstrap that moves .data to ram (if needed) and zeros .bss. But at the same time depending on your system and linker script, you might not have to do either (say a ram based binary like for a raspberry pi, and you place .bss before .data with gnu linker, you neither have to move .data nor have to zero .bss because the objcopy to binary will place it right in the image).

What compiler are you using that C defined global variables can be marked as something other than .bss or .data? And how are you doing that?

Upvotes: 0

Yunnosch
Yunnosch

Reputation: 26763

Before execution of main(), the memory setup takes place.

In case of embedded environments, the built tools (compiler, linker etc.) often bring code files named "crte" (C runtime environment) which have the code for that. Maybe only if you have special (expensive) contract with compiler manufacturer, otherwise they might not allow you that insight.
That code will fill "bss" section with 0 and "data" section with defined values. Often those defined values are found in non-volatile memory in another section called something like "data.rom", it just gets copied to "data" section.

If you create another section, it will not automatically get that convenient service. Not without special precautions. The result is values which happen to be in memory after power-on. Not a really good random number generator, but pretty unpredictable. That would match your description as "garbage value".

Either find out how to get the crte do that, or do it yourself.
The way to get crte to do that is probably the linker directive file. It should allow configurations for user defined sections. Maybe something like "init0", or "init .rom". The manual should of course define that for your environment.

For doing it yourself (probably a commercially less optimal method, i.e. too risky, too time consuming), "just" make sure that some code is executed which writes values to the section - before accessing the variables for the first time. The linker probably publishes symbols into compiler-visible list of identifiers, like "__linker_section__begin" and "__linker_section__end". Use those to get the memory addresses right.

Upvotes: 2

Related Questions