Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30751
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Stack analysis tool that really work? |
| Date | 2021-08-04 16:43 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <see91v$uiq$1@dont-email.me> (permalink) |
| References | <sdukj9$8tu$1@dont-email.me> <sea47k$j3s$1@dont-email.me> <seb3fa$82q$1@dont-email.me> <sed0s0$ehl$1@dont-email.me> |
Il 04/08/2021 05:17, Don Y ha scritto:
> 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?
Most peoples' needs that are similar: have a good estimate of stack
usage worst case.
> 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?")
Oh yes, but a simple tool that generates automatically a call graph
could be very useful for this.
> 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?
I know that compiler can't know everything, but *I* can instruct the
tool with that kind of info.
>> -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.
I think this job could be done by a single tool that creates a call
graph and fill in the values from stack usage.
> 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?)
This is the dynamic approach, I was exploring the static approach.
> 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.
Anyway there are plenty of complex and good free and open-source
software (gcc is one of them).
So it's strange there isn't a similar tool for stack analysis. That's
all, it's strange for me, but I don't pretend all my preferred tools
must be free.
> 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>
Yes, I know these are the only solutions. I was asking if a free tool
really existed but I didn't knew it.
>>> 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