Jump to content
43oh

Why is the stack origin at 0x0400 on mspgcc?


Recommended Posts

Hi,

Once I switched my project from TI compiler (CCS5.3) to mspgcc I was surprised to see the .bss section to decrease from 341 to 178 bytes (MSP430G2553). So I started to dig into the memory map and symbol list to compare those 2 outputs.

 

TI: 

RAM                   00000200   00000200  00000155  000000ab  RWIX

mspgcc, $msp430-read test.elf

   text    data     bss     dec     hex filename
  10666       0     178   10844    2a5c test.elf

 

Now, I can see that the TI locates the stack of 80 bytes (0x50) at the address of 0x03b0:

.stack     0    000003b0    00000050     UNINITIALIZED
                  000003b0    00000002     rts430_eabi.lib : boot.obj (.stack)
                  000003b2    0000004e     --HOLE--
while the mspgcc does it after the RAM area (0x0400 - how is that possible?):

 

$msp430-readelf -s test.elf 

129: 00000400     0 NOTYPE  GLOBAL DEFAULT  ABS __stack

I have not ran this program yet on my hardware as I decomposed all wire connections so I have no idea whether it works or not but I do not understand this stack thing itself - could you please give a hint to the newbie what to read about, where to look for explanation? How is that possible the 341 bytes of .bss dropped down to 178 on the same source code?

 

Best Regards,

tml

 

 

Link to post
Share on other sites

Make sure you have the correct MSP430 specified on the command line. That is one possible cause of the stack being in the wrong place.

Hi,

Thanks for the reply!

It seems it is correct:

Invoking: MSP430 C Compiler
msp430-gcc -O0 -g -Wall -mmcu=msp430g2553 -std=gnu89 -c -o "main.o" "../main.c"
Finished building: ../main.c
Building target: test.elf
Invoking: MSP430 Linker
msp430-gcc  ./main.o  -mmcu=msp430g2553 -o "test.elf"
Finished building target: test.elf

Version:

$msp430-gcc --version
msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 patched to 20120502)

Best Regards,

tml

Link to post
Share on other sites

I think that the way you are looking at where the stack is located is different for CCS and GCC.

 

For CCS you are looking at the start of the allocated stack space (0x03B0), but for GCC you are looking at what the stack pointer is initialized to (0x0400). The stack pointer is used as predecrement, so 0x0400 is correct.

 

Try -Os

Link to post
Share on other sites

I think that the way you are looking at where the stack is located is different for CCS and GCC.

 

For CCS you are looking at the start of the allocated stack space (0x03B0), but for GCC you are looking at what the stack pointer is initialized to (0x0400). The stack pointer is used as predecrement, so 0x0400 is correct.

 

Try -Os

-Os decreases only the .text size and does not impact .bss (which is normal as Os is size-only optimization).

 

Assuming the stack addresses are correct (origin vs. initial pointer) how to explain the significant difference between .bss section sizes?

Link to post
Share on other sites

oPossum is correct: TI reserves a fixed amount of memory for the stack within bss, while mspgcc starts at the top of unused memory and uses as much as it needs without reserving anything.

 

-Os technically could result in decreases in data section size if the code optimizations eliminated the need to store data.  This would probably only happen with static variables that are not marked volatile.

Link to post
Share on other sites

The RAM area starts at 0x0200. However, your stack starts at the end of your RAM area, not the beginning! So if you have 512 bytes of RAM, your stack starts at 0x0200 + 512 - 2. The - 2 is there because 0x0200 + 512 is the first location outside your RAM, and stack is counted in 16-bit words, so 2 bytes.

0x0200 + 512 - 2 = 0x03FE

Link to post
Share on other sites

oPossum is correct: TI reserves a fixed amount of memory for the stack within bss, while mspgcc starts at the top of unused memory and uses as much as it needs without reserving anything.

 

-Os technically could result in decreases in data section size if the code optimizations eliminated the need to store data.  This would probably only happen with static variables that are not marked volatile.

 

Ok, but this makes the opportunity to overwrite the global variables with stack data, doesn't it?

Link to post
Share on other sites

Yes.  AFAIK so does TI's version, unless they're actually checking the bounds of the stack in every function.  They may have an option that enables that, but I expect it isn't turned on by default.  (And exactly what would the program do if the stack does overflow?  Print a message to the console?)

 

The main benefit of the top-of-memory approach is it gives flexibility in memory allocation.  For example, a threaded RTOS may maintain process-specific stacks that are allocated from unused memory.  In many situations the application startup may temporarily require a large stack to perform overall initialization; after that the stack sizes can be tuned to the needs of each process.  As you noticed, a permanently allocated stack block makes that memory unavailable for use later in the application lifetime.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...