Re: [PIC] Learning C

> and then
> to verify that the top values never change.

I think I made a mistake, the test should be:

     if( sp < (uint32_t)&_sstack + SAFETY_MARGIN )


I also noticed an interesting thing, the compiler is extremely clever, 
it detects that we are testing for stack overflow and put this code even 
before allocating the local variables.


Cheers,

Isaac


> That is not 100% guaranteed, because that area could be allocated to 
> an array that is never fully used.
>
> It is very common to have lots of unused "holes" in the stack. I know 
> that because I use RTOSes a lot and often check the stacks of the tasks.
>
> The safest way is checking the stack pointer itself. e.g. (for ARM):
>
>
>     #define SAFETY_MARGIN 128
>
>     extern uint32_t _sstack;
>
>     uint32_t        sp;
>
>     asm volatile( "mov %0,sp" : "=r"(sp) );
>     if( sp < _sstack + SAFETY_MARGIN )
>         { /* Do something... */ };
>

Cheers,

Isaac



Em 19/11/2024 03:54, Forrest Christian (List Account) escreveu:
> So my point really was to point out that being able to determine the 
> status
> of the stack is really implementation defined behavior, and assuming that
> the address of an auto variable is on the stack isn't guaranteed.
>
> As a result one needs to read the compiler manual once you start getting
> into this level of design. In some architectures all auto variables go on
> the stack. In others there is basically no stack and the compiler
> implements it statically. Some architectures have a single stack pointer
> register one can read, others have multiple pointers for different
> functions. All change how you determine the current stack pointer, if one
> even exists.
>
> In the context of detecting an overflow at runtime, one strategy that is
> used is to initialize the stack memory to a known non-zero value and then
> to verify that the top values never change. If they do, you know that
> something has overwritten them probably due to a stack overflow which can
> be handled appropriately.
>
> On Mon, Nov 18, 2024, 11:57 AM smplx <[email protected]> wrote:
>
>> Hi Forrest,
>> Thank you for that, I really appriciate you taking the time to explain!
>>
>> I didn't know XC8 used a static stack. XCSB did this back in 2002
>> (http://xcprod.com/titan/license.html). I guess XC8 caught up. Now all we
>> need to do is wait for compiler aware multitasking (you know, where 
>> we get
>> multiple copies of functions so they can be used concurrently in 
>> different
>> tasks) and builtin efficient comms between tasks.
>>
>> The one thing I REALLY hate is when people claim to produce a C compiler
>> and "Oh, BTW it doesn't do this and that - but it is C". Come on if it
>> isn't 100% C then call it something else - I did :-)
>>
>> Yes I really do understand the implications of a static stack but the
>> poster I was replying to wanted to know how he could perform a sanity
>> check on the stack. If your software is generating a static stack then
>> there is ABSOLUTELY no need for a sanity check and it would be impossible
>> for the software to overflow the stack without the compiler detecting it.
>>
>> FYI if you really want the compiler to generate space on the stack OR 
>> FAIL
>> then there is always "alloc", recursive functions, pointer to functions,
>> seperate compilation units... blah blah blah... I'm sure you could 
>> come up
>> with something than will ALWAY work for portable C code.
>>
>> Really Really Friendly Regards :-)
>> Sergio Masci
>>
>>
>> On Mon, 18 Nov 2024, Forrest Christian (List Account) wrote:
>>
>>> The C standard doesn't mention where automatic duration variables 
>>> (like x
>>> in your example) will be stored. It leaves that 100% up to the
>> compiler.
>>> It could be on the stack, or it could be some static allocation, or it
>>> could be a register, or somewhere else.
>>>
>>> A good example is XC8, and other compilers for the 8 bit PICs. It does
>>> what it calls static stack allocation. How it works is somewhat easy to
>>> explain:
>>>
>>> Every auto variable that won't fit in a register is assigned a specific
>>> memory address which never changes for a particular build of the code.
>>> Because XC8 is aware of the call tree, it is able to assign these
>> variables
>>> in a way that variables that are never "active" at the same time can
>> share
>>> the same memory space. For example, all library functions that use a
>>> temporary variable and then return can use the exact same space for 
>>> those
>>> variables. On the other hand, an auto variable which exists in main()
>>> will need to be assigned a dedicated space which is not reused.
>>>
>>> This also simplifies the output code. Instead of having to deal with the
>>> stack pointer, the functions can then just go after the memory directly.
>>> This does cause problems for functions which are called by interrupt
>>> routines and as such, the compiler will duplicate functions which are
>> used
>>> by the main program and interrupts, compiling each to their own set of
>>> variables. XC8 or one of the other compilers I've used will emit a
>> warning
>>> when it does that. I'll usually use that as an excuse to look at the
>>> called function and determine if it can be eliminated from the interrupt
>> in
>>> some way that improves the code.
>>>
>>> One other note is that "statically compiled stacks" like this don't
>> support
>>> recursion as it's impossible to tell the call depth. As a result, either
>>> the compiler will fail the compile with an error, or in some cases the
>>> compiler will do a dynamic stack just for the recursive functions.
>>> Looking at the XC8 compiler docs it looks like on larger PICs with 
>>> better
>>> support for a stack it supports this mixed methodology.
>>>
>>> Note that this whole issue is one of the reasons why the AVR crowd used
>> to
>>> point at their core and said it was better for C, since it has better
>> stack
>>> support and also has other features which are more useful for C such as
>> (if
>>> I recall correctly) more data registers to store temporary values in.
>>>
>>> One final note: Any C complier which compiles for hardware with a very
>>> restricted or non-existent stack is going to have to support some 
>>> sort of
>>> method for having auto variables not being on the stack. Even if that
>>> support is to tell the programmer that they need to fix this (or worse,
>>> produce a broken executable).
>>>
>>> On Mon, Nov 18, 2024, 4:01 AM smplx <[email protected]> wrote:
>>>
>>>> Hi Forrest,
>>>> I am intrigued by what you say. Could you please point me at any
>> specific
>>>> embedded C compilers that do this.
>>>>
>>>> Friendly Regards
>>>> Sergio Masci
>>>>
>>>> On Sun, 17 Nov 2024, Forrest Christian (List Account) wrote:
>>>>
>>>>> With many embedded compilers, x may or may not be on the stack, as the
>>>>> compiler will, in some cases, use non-stack memory for local
>> variables.
>>>>> This is especially true on smaller microcontrollers with limited stack
>>>>> space.
>>>>>
>>>>> One would need to read the compiler manual to determine if x will
>> always
>>>> be
>>>>> on the stack, whether there is a way to force x to be on the stack,
>> or
>>>> if
>>>>> there is a compiler specific way to get the stack pointer.
>>>>>
>>>>> On Sat, Nov 16, 2024, 4:09 AM smplx <[email protected]> wrote:
>>>>>
>>>>>> write a function:
>>>>>>
>>>>>> void * get_stack_ptr(void)
>>>>>> {
>>>>>> int x;
>>>>>>
>>>>>> return &x;
>>>>>> }
>>>>>>
>>>>>> This will return the address of the local variable x which will be on
>>>> the
>>>>>> stack.
>>>>>>
>>>>>> use it as:
>>>>>>
>>>>>> if ((unsigned long)get_stack_ptr() == (unsigned
>>>> long)fixed_value+N)
>>>>>> // where N is a constant TBD (around +/- 4 to 12)
>>>>>>
>>>>>>
>>>>>> On Fri, 15 Nov 2024, David VanHorn wrote:
>>>>>>
>>>>>>> Same here. I can work with c fairly well, but some things seem
>>>> unusually
>>>>>>> difficult in c. Like comparing the current value of the stack
>> pointer
>>>>>> to a
>>>>>>> fixed value ( used in my sanity check routine) I assume there is a
>>>> way
>>>>>> to
>>>>>>> get there.
>>>>>>>
>>>>>>> On Sun, Nov 10, 2024, 11:34 AM David C Brown <[email protected]>
>>>> wrote:
>>>>>>>> Although I enjoy programming in Assembler, the fact that so many
>>>>>> libraries
>>>>>>>> abd code examples are in C I think that the time has come for me
>> to
>>>>>> learn
>>>>>>>> that language.
>>>>>>>>
>>>>>>>> Any advice on how to do that would be welcomed, be it a book or
>>>> online
>>>>>>>> resources.
>>>>>>>> I am a competent programmer having programmed in with Forth,
>>>> Fortran.
>>>>>>>> \Pascal, Visual basic
>>>>>>>> __________________________________________
>>>>>>>> David C Brown
>>>>>>>> 43 Bings Road
>>>>>>>> Whaley Bridge
>>>>>>>> High Peak Phone: 01663 733236
>>>>>>>> Derbyshire eMail: [email protected]
>>>>>>>> SK23 7ND web: www.bings-knowle.co.uk/dcb
>>>>>>>> <http://www.jb.man.ac.uk/~dcb>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *Sent from my etch-a-sketch*
>>>>>>>> --
>>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>>>> View/change your membership options at
>>>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>>>>
>>>>>>> --
>>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>>> View/change your membership options at
>>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>> --
>>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>>> View/change your membership options at
>>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>>>
>>>>> --
>>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>>> View/change your membership options at
>>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>> --
>>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>>> View/change your membership options at
>>>> https://mailman.mit.edu/mailman/listinfo/piclist
>>>>
>>> --
>>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>>> View/change your membership options at
>>> https://mailman.mit.edu/mailman/listinfo/piclist
>> --
>> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
>> View/change your membership options at
>> https://mailman.mit.edu/mailman/listinfo/piclist
>>

-- 
O software antivírus Avast realizou uma checagem de vírus neste e-mail.
www.avast.com
-- 
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
https://mailman.mit.edu/mailman/listinfo/piclist