CODEWITHSUNDEEP
clinuxgccshared-libraries
user184968
user184968

Reputation:

What might be the point in putting a variable exactly in the "STACK" section with __attribute__ ((section("STACK"))?

In gcc doc one reason is given for using section. This reason is to map to special hardware. But this seems to be not my case.

So I have given a task to modify a shared library that we use on our project. It is a Linux library. There is variable declarations in the library that puzzeles me. They look like this (roughly):

static int my_var_1 __attribute__((section("STACK"))) = 0;

Update 1:
There are a dozen of variables defined in this way (__attribute__((section("STACK"))))

Update 2:
my_var_1 is not a constant. my_var_1 might be changed in code during initialization:

my_var_1 = atoi(getenv("MY_VAR_1") ? getenv("MY_VAR_1") : "0");

later in the library it is used like this:

inline void do_something() __attribute__((always_inline));
inline void do_something()
{
  if (my_var_1)
    do_something_else();
}


What might be the point in using __attribute__((section("STACK")))? I understand that section tells the compiler to put a variable in the particular section. However what might be the point in putting static int exactly in the "STACK" section?

Update 3
These lines are excerpt from the output from readelf -t my_lib.so

  [23] .got.plt
       PROGBITS         00000000002103f0  00000000000103f0  0
       00000000000003a8 0000000000000008  0                 8
       [0000000000000003]: WRITE, ALLOC
  [24] .data
       PROGBITS         00000000002107a0  00000000000107a0  0
       00000000000000b0 0000000000000000  0                 16
       [0000000000000003]: WRITE, ALLOC
  [25] STACK
       PROGBITS         0000000000210860  0000000000010860  0
       00000000000860e0 0000000000000000  0                 32
       [0000000000000003]: WRITE, ALLOC
  [26] .bss
       NOBITS           0000000000296940  0000000000096940  0
       0000000000000580 0000000000000000  0                 32
       [0000000000000003]: WRITE, ALLOC

Update 4
Managed to get information from the author of the shared library. __attribute__((section("STACK"))) was added since he had not managed to build the library on Solaris. Then he found this workaround. Before the workaround the definition of the my_var_1 was like:

int my_var_1 = 0;

and everything was OK. Then he changed it since my_var_1 was in fact needed only in this translation unit:

static int my_var_1 = 0;

And after that change he did not manage to build the library on Solaris. So he added __attribute__((section("STACK"))) and it helped somehow.

Upvotes: 5

Views: 361

Answers (3)

supercat
supercat

Reputation: 81247

In some operating systems, the same region of addressing space is used for every thread's stack; when execution switches between threads, the mapping of that space is changed accordingly. On such systems, every thread will have its own independent set of any static variables located within that region of address space. Putting variables that need to be maintained separately for each thread in such an address range will avoid the need to manually swap them with each task switch.

Another occasional use for forcing variables into a stack area is to add stack sentinels (variables that can be periodically checked to see if a stack overflow clobbered them).

A third use occurs on 8086 and 80286 platforms (probably not so much later chips in the family): the 8086 and 80286 are limited to efficiently accessing things in four segments without having to reload segment registers. If code needs to do something equivalent to 

for (n=0; n<256; n++)
  *dest++ = xlat[*src++];

and none of the items can be put in the code segment, being able to force one of the items into the stack segment can make code much faster. Hand-written assembly code would be required to achieve the speedup, but it can be extremely massive (nearly a factor of two in some real-world situations I've done on 8086, and perhaps even greater in some situations on the 80286).

Upvotes: 0

gby
gby

Reputation: 15218

There may be many reasons and it is difficult to tell without details. Some of the reasons might be:

  1. The section marked STACK is linked in run-time to a closely coupled memory with faster access time then other RAMs. It makes sense to map the stack to such a RAM to avoid stalls during function calls. Now if you suddenly had a variable that is accessed a lot and you wanted to map it to the same fast access RAM putting it in the same section as the stack makes sense.

  2. The section marked STACK might be mapped to a region of memory that is accessible when other parts of memory might not be. For example, boot loaders need to init the memory controller before they can access RAM. But you really want to be able to write the code that does that in C, which requires stack. So you find some special memory (such as programming the data cache to write-back mode) and map the stack there so you can run code to get the memory controller working so you can use RAM. Once again, if you now happen to have a global variable that still need to be accessed before RAM is available, you might decide to put it in the STACK section.

A better programmer would have renamed the STACK section to something else if it is used not only for stack.

Upvotes: 1

Nimlar
Nimlar

Reputation: 655

First the STACK section won't be the stack of any running task.

Putting variables, functions in a specific Section allow to select a memory area for them (thanks to the linker script). On some (mostly embedded) architecture, you want put often accessed data in the faster memory.

Other solution, some development post-link script will set all the STACK section to 1: a development software will always do do_something_else(). And the released software may keep the default value of 0.

An other possibility, if there are other variables in the STACK section, the developer wants to keep them close in the memory. All Variable in the STACK section will be near each other. Maybe a cache optimization ?

Upvotes: 5

Related Questions