Software stack checking and 'attribute conflict'

Software stack checking and 'attribute conflict'

Description
Software stack checking is often vital during the early stages of software development, to catch misbehaving programs. To enable software stack checking, simply compile with '-apcs /swst '. Code which overflows the stack can then be trapped and corrected. This can also help with estimating the stack size requirements. Once stack usage is known then software stack checking may be disabled (compile with '-apcs /noswst'), if preferred.

For many embedded products e.g. mobile phones, which can execute only a limited number of well-defined applications and where the stack requirements can be predicted, the overhead (in terms of cost & additional complexity) of stack checking is often unjustifiable, so 'no stack checking' is often the preferred option.

For more complex products e.g. PDAs, which can run a number of applications (known only at run time), where stack requirements are not known in advance, software (or maybe hardware) stack checking may be required.

Solution

For SDT 2.50/2.51, software stacking checking is disabled by default for both armcc and tcc.
For SDT 2.11/2.11a, software stacking checking is enabled by default for armcc, and disabled by default for tcc.

Software stack checking for user-mode tasks requires the use of a register to hold the stack limit (sl = r10, according to the APCS), and a compare/branch on entry to each function. When software stack checking is enabled (with '-apcs /swst'), the compiler adds instructions on entry to each function to check if the stack has overflowed or not, like this:

For ARM code:

    stmfd   sp!,{lr}
    cmp     sp,r10
    blmi    __rt_stkovf_split_small
      : 

For Thumb code:

    push    {lr}
    cmp     sp,r10
    bge     skip
    bl      __16__rt_stkovf_split_small
skip...
      : 

...where r10 contains the stack limit.

If you try to link code built with software stack checking on ('/swst') together with code built with no software stack checking ('/noswst'), the linker will warn of an 'attribute conflict'. It is very dangerous to ignore this warning from the linker, for the following reason:

• If software stack checking is enabled, r10 is assumed to be dedicated for the stack limit.
• If software stack checking is disabled, r10 is assumed to be free for use by the register allocator.

Clearly, if code with stack checking is mixed with code without stack checking then chaos may ensue! In practice, this means that all code and libraries must be built with the same 'software stack check' attributes, either all on or all off.

When linking with libraries supplied with the ARM SDT 2.x, you can tell how each library has been built by its file naming convention, e.g. armlib_s.16l is a Thumb little-endian library with software stack checking enabled.
SDT 2.50/2.51 users should refer to SDT 2.50 Reference Guide, Chapter 4, 'The C and C++ Libraries'.
SDT 2.11/2.11a users should refer to SDT 2.11 Reference Guide, section 3.7, 'C Libraries'.

Once stack usage is known then software stack checking may be disabled. This frees-up a register (r10) for use as a work register and saves two instructions on entry to each function (three for Thumb), so is ideal for Thumb-based systems where code size is critical.

来源于 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3702.html