Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30895 > unrolled thread

Worst case stack

Back to article view | Back to comp.arch.embedded

Contents

  Worst case stack pozz <pozzugno@gmail.com> - 2021-11-17 17:30 +0100
    Re: Worst case stack Paul Rubin <no.email@nospam.invalid> - 2021-11-17 12:28 -0800
      Re: Worst case stack David Brown <david.brown@hesbynett.no> - 2021-11-18 10:16 +0100
    Re: Worst case stack Clifford Heath <no.spam@please.net> - 2021-11-18 10:21 +1100
      Re: Worst case stack pozz <pozzugno@gmail.com> - 2021-11-18 08:47 +0100

#30895 — Worst case stack

I found a nice tool[1] on GitHub.

I run it on one of my embedded projects and after a couple[2] of fixes, 
it eventually printed some good output.

There were many unresolved functions, mainly from libc, C runtime, 
interrupts. I defined all of them in .msu, so now in the final output 
there aren't unresolved functions.

Now there's another big problem. Many functions have an unbounded stack 
usage and I'm quite sure this depends on function pointers.

For example, I use this[3] printf library. It uses function pointer to 
emit characters: sprintf calls _vsnprintf() with _out_buffer() function 
pointer; printf calls _vsnprintf() with _out_char() function pointer.

So sprintf-like functions have an unbounded stack usage, because the 
poor tool wcs.py isn't able to understand that there are only a few 
possibilities for the first argument (the function pointer) of _vsnprintf().

It's a pity it isn't possible to set a list of functions for certain 
functions pointers so wcs.py could print a better result.





[1] https://github.com/PeterMcKinnis/WorstCaseStack

[2] The tool emitted some errors on a few WEAK functions that are 
interrupt handlers. I used .msu file to set a stack usage for those.

Another problem is in print_all_fxns() function and the access to 
fxn_dict2['demangledName'].
For some functions (I think the functions defined in .msu) there weren't 
'demangledName' so I print the simple 'name'.

[3] https://github.com/mpaland/printf

[toc] | [next] | [standalone]

#30896

pozz <pozzugno@gmail.com> writes:
> It's a pity it isn't possible to set a list of functions for certain
> functions pointers so wcs.py could print a better result.

I think MISRA C disallows function pointers, partly for this reason.

[toc] | [prev] | [next] | [standalone]

#30900

On 17/11/2021 21:28, Paul Rubin wrote:
> pozz <pozzugno@gmail.com> writes:
>> It's a pity it isn't possible to set a list of functions for certain
>> functions pointers so wcs.py could print a better result.
> 
> I think MISRA C disallows function pointers, partly for this reason.
> 

MISRA C contains no such rule, as far as I could see (in MISRA C 2012).
 It has some rules about what you can do with function pointers, but
they are just some of the pointless "you have to write valid C" rules.

Function pointers are a tool that can be very useful for reducing
inter-dependency between different modules.  But they should be avoided
where they are not needed, as they have a lot of disadvantages.  They
are easy to get wrong, and hard for tools to check automatically.  Stack
analysis tools are one example here, as are other tools for flow
analysis (such as doxygen-generated call graphs) - it's also hard to
follow them manually to see when a function might be called if it is
used via function pointers.  (They can also be less efficient in use, as
the compiler knows less about them.)

[toc] | [prev] | [next] | [standalone]

#30897

On 18/11/21 3:30 am, pozz wrote:
> I found a nice tool[1] on GitHub.
> 
> I run it on one of my embedded projects and after a couple[2] of fixes, 
> it eventually printed some good output.
> 
> There were many unresolved functions, mainly from libc, C runtime, 
> interrupts. I defined all of them in .msu, so now in the final output 
> there aren't unresolved functions.
> 
> Now there's another big problem. Many functions have an unbounded stack 
> usage and I'm quite sure this depends on function pointers.
> 
> For example, I use this[3] printf library. It uses function pointer to 
> emit characters: sprintf calls _vsnprintf() with _out_buffer() function 
> pointer; printf calls _vsnprintf() with _out_char() function pointer.
> 
> So sprintf-like functions have an unbounded stack usage, because the 
> poor tool wcs.py isn't able to understand that there are only a few 
> possibilities for the first argument (the function pointer) of 
> _vsnprintf().
> 
> It's a pity it isn't possible to set a list of functions for certain 
> functions pointers so wcs.py could print a better result.

It's not just function pointers (in fact the printf thing should be 
resolvable), it's recursion, alloca(), variable-sized arrays (a gcc 
extension), and other things. In general it is not a computable problem.

[toc] | [prev] | [next] | [standalone]

#30898

Il 18/11/2021 00:21, Clifford Heath ha scritto:
> On 18/11/21 3:30 am, pozz wrote:
>> I found a nice tool[1] on GitHub.
>>
>> I run it on one of my embedded projects and after a couple[2] of 
>> fixes, it eventually printed some good output.
>>
>> There were many unresolved functions, mainly from libc, C runtime, 
>> interrupts. I defined all of them in .msu, so now in the final output 
>> there aren't unresolved functions.
>>
>> Now there's another big problem. Many functions have an unbounded 
>> stack usage and I'm quite sure this depends on function pointers.
>>
>> For example, I use this[3] printf library. It uses function pointer to 
>> emit characters: sprintf calls _vsnprintf() with _out_buffer() 
>> function pointer; printf calls _vsnprintf() with _out_char() function 
>> pointer.
>>
>> So sprintf-like functions have an unbounded stack usage, because the 
>> poor tool wcs.py isn't able to understand that there are only a few 
>> possibilities for the first argument (the function pointer) of 
>> _vsnprintf().
>>
>> It's a pity it isn't possible to set a list of functions for certain 
>> functions pointers so wcs.py could print a better result.
> 
> It's not just function pointers (in fact the printf thing should be 
> resolvable), it's recursion, alloca(), variable-sized arrays (a gcc 
> extension), and other things. In general it is not a computable problem.

Yes, in general there are many obstacles to calculate analitically the 
worst case stack usage.

Howevere I was talking of *my* project where I don't use recursion, 
alloca() and so on. I'm quite sure the only problem is with function 
pointers and it's a pity it's not possible to say those kind of tools 
which values certain function pointers could have, so it could be able 
to calc the worst case precisily.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web