generalise the stack checking functions

2013-02-09
2013-09-16
  • Hi Richard!

    I've just posted the patch

    generalise the stack checking functions on the Feature Requests tracker.

    This patch enables ports of FreeRTOS to architectures which use/need more than
    one stack.

    To support the stack overflow checking functionality on such a port for the
    additional stack(s), we need to have general (inline) functions where the stack
    and such is not hard-coded.

    Tested on a real hw with configCHECK_FOR_STACK_OVERFLOW == 2 and
    portSTACK_GROWTH == -1.

    Just compile tested for portSTACK_GROWTH == +1.

    Would be nice if you could mainline this.

    Regards
    Friedl

     
  • Richard
    Richard
    2013-02-11

    I have not done more than glance at this one yet.  I understand the desire to generalise the stack checking, but the patch is not there yet because it uses inline functions (remember FreeRTOS officially compiles with 18 different compilers so avoids using inline as different standards treat it differently ).  Also, the checking has to be very fast, hence the macros that are expanded inline rather than function calls.  I'm not sure (because I don't use them often) if the compiler will always perform a direct substitution for an inline function without any parameter overhead.  I suspect most compilers will as soon as you turn any kind of optimisation on.

    I will look at what you are trying to achieve to see if there is an alternative that does not use the inlines.

    Regards.

     
  • Richard
    Richard
    2013-02-11

    Only partially related - I would be interested to know what you are porting to.

    Regards.

     
  • I will look at what you are trying to achieve to see if there is an alternative that does
    not use the inlines.

    I used the inline to get type checking while using defines.

    Because the inlines are in a .h file the compiler has to put
    the code where the define goes. Am I wrong?

    Regards Friedl

     
  • I would be interested to know what you are porting to.

    It's not 8051 :-)

    Regards
    Friedl