|
Hello, I'm writing a C6415 app with CCS2.1. I have some problems with the linker. The __STACK_SIZE symbol is defined by the linker and used to initialise the stack pointer. If I look in my .map file, I see that this symbol is placed at the same address as my vector table's first entry (reset vector). It look like the linker is placing the symbol just after the .stack region. In my case, the vector table is just following my stack section. Is it normal that the linker doesn't perform any check before placing this symbol (thus overwriting some data) ? Do you know if there's a way to force the linker to place this symbol somewhere else ? Thanks for your help J-F |
|
|
Position of __STACK_SIZE symbol
Started by ●March 15, 2002
Reply by ●March 15, 20022002-03-15
|
I think that __STACK_SIZE is the size of the stack, not its position in memory. You could think of it as a compile time constant that doesn't exist anyway in the memory map. Look for the .stack section to see exactly where in the DSP's address space the stack has been located. Andrew E. At 11:10 AM 3/15/02 +0000, jfbuggen wrote: >Hello, > >I'm writing a C6415 app with CCS2.1. I have some problems with >the linker. > >The __STACK_SIZE symbol is defined by the linker and used >to initialise the stack pointer. > >If I look in my .map file, I see that this symbol is placed >at the same address as my vector table's first entry (reset vector). > >It look like the linker is placing the symbol just after >the .stack region. In my case, the vector table is just following >my stack section. > >Is it normal that the linker doesn't perform any check before >placing this symbol (thus overwriting some data) ? > >Do you know if there's a way to force the linker to place this >symbol somewhere else ? > >Thanks for your help > >J-F > >_____________________________________ >Note: If you do a simple "reply" with your email client, only the author of >this message will receive your answer. You need to do a "reply all" if you >want your answer to be distributed to the entire group. > >_____________________________________ >About this discussion group: > >To Join: Send an email to > >To Post: Send an email to > >To Leave: Send an email to > >Archives: http://www.yahoogroups.com/group/c6x > >Other Groups: http://www.dsprelated.com >">http://docs.yahoo.com/info/terms/ |
Reply by ●March 15, 20022002-03-15
|
jfbuggen wrote: > Hello, > > I'm writing a C6415 app with CCS2.1. I have some problems with > the linker. > > The __STACK_SIZE symbol is defined by the linker and used > to initialise the stack pointer. > > If I look in my .map file, I see that this symbol is placed > at the same address as my vector table's first entry (reset vector). > > It look like the linker is placing the symbol just after > the .stack region. In my case, the vector table is just following > my stack section. > > Is it normal that the linker doesn't perform any check before > placing this symbol (thus overwriting some data) ? > > Do you know if there's a way to force the linker to place this > symbol somewhere else ? > > Thanks for your help > > J-F It seems that the linker is missing a directive to place the vector section (e.g. .vec: align24{} > IPRAM ). Hence, it may missplace it following .stack Rgds. Phil |
Reply by ●March 15, 20022002-03-15
|
> >Your right > >__STACK_SIZE is a pseudo-symbol that doesn't points anywhere. C.W. wrote : > By which you mean _STACK_SIZE has a VALUE which is NOT AN ADDRESS, but > which is the SIZE of the allocated stack, right? > > So while it appears to the original user that it's value is the same as the > address of their vector section, it's merely a coincidence. If they change > the size of the allocated stack (RTFM), the coincidence will no longer exist. Exact. Change the "-s nnnn" parameter and you will see the change being reflected by the __STATCK_SIZE symbol change of value. You can do the same with "-h nnn" for __SYSMEM_SIZE. By the way, you can force any of these symbols to another value if you want by setting them to a new value into the CMD file. For example, if you place : -s 0x400 __STACK_SIZE = 0x1000 in your CMD file, the symbol value will be changed. So the code managing the stack will consider it to be 0x1000 bytes. But the linker has allocated 0x400 to the stack !!!! There is a more useful trick concerning the heap size. I have always found it boring to adjust my heap size when my code/data size change to get the maximum heap possible. So have a look at that CMD file : MEMORY { /* let's have 16MB SDRAM on my C6201 */ SDRAM: org = 0x00000000 len = 0x1000000 /* other memory not shown ... */ } SECTIONS { /* allocate all sections except .sysmem */ .... /* now allocates .sysmem as the last section */ .sysmem { __SYSMEM_SIZE = 01000000h - .; } > SDRAM } What is that doing (except generating a warning at the link stage :) ? The . represents the current allocation point of the linker. So when it starts locating .sysmem in memory, it starts by executing the expression into the braces. The expression force __SYSMEM_SIZE to get the result of <end of SDRAM addresse> - <start of .sysmem> So __SYSMEM_SIZE now has the size of the whole buch of memory from the start of .sysmem to the end of SDRAM This is very usefull ... But for that to work correctly, you MUST have .sysmem allocation as the last line in your section because for the linker, .sysmem will have the size specified in the -h command. So if another section was allocated behind .sysmem size, it will be overlapped with the heap that the malloc code think it is. Hope this was clear. Regards, Jean-Michel MERCIER ------------------- http://www.ateme.com ATEME - 26 Burospace - 91573 BIEVRES Tel : +33 (0)1 69 35 89 73 (direct) Fax : +33 (0)1 60 19 13 95 |
