Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30750
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Stack analysis tool that really work? |
| Date | 2021-08-03 20:17 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <sed0s0$ehl$1@dont-email.me> (permalink) |
| References | <sdukj9$8tu$1@dont-email.me> <sea47k$j3s$1@dont-email.me> <seb3fa$82q$1@dont-email.me> |
On 8/3/2021 2:49 AM, pozz wrote:
> Il 03/08/2021 02:56, Don Y ha scritto:
>> On 7/29/2021 9:22 AM, pozz wrote:
>>> arm gcc and Cortex-Mx MCUs embedded systems.
>>>
>>> Is there a compilation-time (static) tool for stack analysis that really works?
>>
>> What do you mean by "really works"? It's a (potentially) unbounded problem
>> as the compiler can't know what the inputs will drive the code to do, in
>> practice.
>
> I mean a simple tool that can be instructed, even manually, to produce a good
> result.
What's "good"? Does it have to solve *most* peoples' needs? Or, just yours?
As I said, the first step is understanding what the dynamics of execution
in your task happen to be. You may be surprised to see functions being
dragged in that you'd not have thought were part of the mix! ("why is
printf() being called, here?? and, couldn't I use something like itoa()
instead?")
The compiler won't know anything about your run-time environment. It won't
know if you have a separate stack for ISRs, if the function you are analyzing
runs as the "root" of a particular process tree, etc. Do you know how much
work is done BEFORE the first line of your function executed?
It also won't know which execution paths *will* be exercised in practice.
You may have paths that can't be executed (given a particular set of
inputs). How will you know to recognize their impact on any figures
reported?
> -fstack-usage is not usable "by hands".
No, but you can use that data *with* the call tree to get an idea of
where your maximum lies -- assuming no recursion and worst-case path
coverage.
You can also fill the stack space with 0x2B00B1E5, run your COMPREHENSIVE
test case suite that exercises ALL paths through the code and check to see
what the high-water mark was. (you *are* testing the code, right?)
Hint: you *really* want tasks to be of the lowest practical complexity
that can meet your requirements -- even if that means splitting tasks
into more subunits.
> You need at least a call-graph (generated by a tool), fill each branch
> (function) with a stack usage (generated by the compiler),
These can be done with a script (as I suggested below)
> fill every branch
> that is not known at compilation time by the tools (call functions by pointers,
> recursive, and so on).
Ah, well... there's the rub! How smart should this "free" tool be?
And, how should it handle cases that can't be known at compile time
("Sorry, your codebase appears to need AT LEAST X bytes of stack; but,
I can't tell you how much more!" -- what use, that?)
> It's surprisingly to me there isn't a single non-expensive tool that helps in
> this, considering there are a multitude of good free tools for developers.
It costs money to engage in any business (non-hobbyist) endeavor.
Expecting all of your tools to be "free" is a bit naive.
There are some absolutely *amazing* tools available that can save
man-years of development effort and greatly improve the quality/correctness
of code. You can buy them -- or, spend man-hours trying to do what they
do. Hopefully, without error.
And, having *done* that, do it all over again on your NEXT project!
<frown>
>> Your best practical option is to tease a callgraph (tree) out and use your
>> own knowledge of what the code WANTS to do to identify the worst-case
>> stack penetration path. This is also a great way to get a feel for if your
>> code might benefit from a good refactoring!
>>
>>> The best I could find is -fstack-usage and avstack.pl Perl script, but I
>>> guess there's another and better way.
>>
>> There are general tools that you can probably instrument to coax a
>> number out of the source (if you don't have access to the source, you're
>> typically SoL) but they will be expensive in time or money.
*Try* building the call tree (there are some graphic tools) and
have a look at it. Is it what you expected? Do you understand
*why* each function is being invoked in each edge?
Then, try to *guess* where the "stack pigs" are located.
Finally, see what the compiler tells you for each of them and
how well that fits with your "understanding" of the code.
[The reason you want to do this is so you have a better feel
for the costs of particular approaches -- instead of just
reacting to the "final assessment". For example, most newbies
are stunned to discover how expensive an off-the-shelf
printf() can be!]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-07-29 18:22 +0200
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-07-29 19:36 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-02 17:56 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-03 11:43 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 02:28 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 22:14 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:43 -0700
Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-03 11:49 +0200
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-03 20:17 -0700
Re: Stack analysis tool that really work? pozz <pozzugno@gmail.com> - 2021-08-04 16:43 +0200
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 11:06 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 12:00 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:54 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 20:00 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 10:50 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-04 21:50 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-04 15:46 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:43 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 06:16 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 18:39 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 01:09 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-06 22:58 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:04 -0700
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-06 16:06 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:20 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:26 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:46 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 15:14 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 14:09 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 08:09 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 19:50 +0300
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 20:02 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-07 10:34 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 21:10 +0300
Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-06 22:55 -0400
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-07 13:40 +0300
Re: Stack analysis tool that really work? George Neuner <gneuner2@comcast.net> - 2021-08-08 18:34 -0400
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 10:50 +0300
Re: Stack analysis tool that really work? Paul Rubin <no.email@nospam.invalid> - 2021-08-09 11:26 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-09 22:59 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-09 12:04 -0700
Re: Stack analysis tool that really work? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2021-08-05 13:18 +0300
Re: Stack analysis tool that really work? Don Y <blockedofcourse@foo.invalid> - 2021-08-05 04:59 -0700
csiph-web