• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 541 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/CCSTUDIO: Why the "-stack = Anysize" command in ARM linker command file seems useless?

Wang Wei
Prodigy 240 points
Part Number: CCSTUDIO


Tool/software: TI C/C++ Compiler

My working tool is CCS8.0.0 with compiler version of  TI v18.1.1.LTS.

In the linker command file, I noticed that the stack size has been set by the "-stack = 0x0008" command line by someone else.

And the generated map file shows that the stack size does have been set to only 8 bytes as in the picture below.

But there's no doubt that the actual size of stack is much larger than 8 bytes. The location of stack bottom is 0x87FFFFF0, when I just run into the "main" function, the stack top has grown to addr 0x87F8A9E8 which tells the size of stack is already nearly 469KB as shown in the picture below.

So my problems are that:

1. Is the "-stack = anysize" command useless in linker command file?

2. How can I define the size of stack explicitly and accurately?

I have attached the linker cmd file and corrsponding map file.

Thanks and best regards!

map and cmd file.rar

  • 0
    TI__Guru**** 251200 points

    I suspect you got this linker command file from StarterWare for AM335x.  Is that correct?  StarterWare is no longer supported.  It would be better if you changed to the Processor SDK for AM335x.  

    Is that a practical alternative for you?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 240 points

    Yes, the cmd file derives from StarterWare for AM335x.

    Our project has been using the StarterWare all the way since several years ago, I don't think our project manager has enough motives to migrate from StarterWare to Processor SDK for the current product.

    George Mock said:
    StarterWare is no longer supported

    Do you mean this problem is indeed a kind of bug in StarterWare toolchain?

    If there is a proper way to accurately set the size of stack just basing StarterWare?

    Thanks and best regards!

  • 0 in reply to Wang Wei
    TI__Guru**** 251200 points

    I am not familiar with StarterWare.  But I do know linker command files.  While I cannot explain everything, I can shed some useful light.

    The way most projects size the stack is not how StarterWare does it.  Here is how it worked prior to when you made changes I recommended to avoid a large hole that causes the binary file to be very large.  This line ...

    -stack  0x0008                             /* SOFTWARE STACK SIZE           */

    creates a stack section with a size of 8 bytes.  This line ...

        .stack   : load > 0x87FFFFF0           /* SOFTWARE SYSTEM STACK         */

    ... locates that small stack section 16 bytes from the very end of memory.  The stack grows from high addresses to low addresses.  Startup code must initialize the SP register to the base address of this small stack section.  So, the effective size of the stack is from the high end of memory until the end of whatever other section gets located at the next highest memory address.  Another way to think of it: This made the stack as large as possible.  

    Then you made some changes to the linker command file, suggested by me, in order to avoid the large binary file.  One change is adding this memory range ...

    FOR_STACK   : org = 0x87FFFFF0  len = 0x1000

    Note it is important that the line which allocates the small stack section to memory not change.  

        .stack   : load > 0x87FFFFF0           /* SOFTWARE SYSTEM STACK         */

    The combined effect of these two lines is that the size of the stack is the length of the FOR_STACK memory range, or 0x1000 bytes in this case.  This change is necessary because, in the memory range adjacent to FOR_STACK, a few sections are located using the HIGH specifier.  That is, they are located at the highest address available in that memory range.  Or, right up against where FOR_STACK begins.  If 0x1000 is not enough stack, make the length of FOR_STACK larger.

    Thanks and regards,

    -George