On Thu, Apr 19, 2012 at 7:37 AM, Doug Carlson <carl...@cs.jhu.edu> wrote: > Howdy. > I recently ran into an issue with my program stack growing into the > statically-allocated variables in the .bss section due to some > overenthusiastic use of printf's. Looking through the archives, I found this > discussion<http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg10178.html> > regarding > general stack protection techniques. > > Two questions, which may be more general gcc/ld-related than msp-specific > > 1. While it's impossible in the general case to determine the maximum stack > size that a program will use, is there any mspgcc setting (or standalone > tool) that can handle the simple cases that dominate in MCUs (no recursion, > no function pointers, no nested ISRs) and spit out a maximum stack depth?
Not that I know of. > > 2. Failing that, what is the preferred method for indicating that X bytes > should be reserved at the top of RAM, and violations of this should result > in a linker error? It looks like the .noinit section gets placed where I > want it, so I see a couple of options: > > a. Use the RESERVE_RAM > annotation<http://mspgcc.sourceforge.net/manual/x1023.html> on > the main method. This is somewhat undesirable to me because I'm working in It also probably won't work. I don't think that feature is present anymore; there are other ways to reserve RAM above the stack (these involve replacing a function in a CRT section). > TinyOS and this would introduce what seems to be an msp-gcc specific change > to an otherwise platform-independent core file. It's not a deal-breaker, > but I'd like to avoid it if possible. Unless avr-gcc supports this and I'm > just not finding it in the documentation. > > b. Use the section attribute, something like this: > char __attribute__ ((section(".noinit"))) stack_space[RESERVED_STACK_SIZE]; > > where RESERVED_STACK_SIZE is based on either observation or the type of > analysis described above. This appears to be somewhat supported by > avr-gcc<http://nongnu.org/avr-libc/user-manual/mem_sections.html#sec_dot_noinit> > . > > c. Some unknown-to-me command in the linker script that forces a particular > section to be of a given size, regardless of what symbols are actually > supposed to be placed there. I don't see how this would help. Data is placed starting at the lowest RAM address, and takes as much space as is required. The stack pointer is initialized to the top of the RAM and grows downward. Nothing that the linker does will stop the stack pointer from being decremented into the area where the linker placed data. At best, you'd be able to detect at link time that your static data is too large, but you don't need linker support to do that (check the output of msp430-size). At runtime you can find the addresses where the link placed data using features in <sys/crtld.h>, so you could theoretically check the stack pointer against a value and detect an overflow (too late to do anything about it except panic, though). Peter > > Any suggestions would be most appreciated. > > Thanks! > Doug Carlson > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
