Re: [avr-gcc-list] Strange compile behaviour

[Bernard Fouché]

Hi All.

I still have at hand that nice perl script from John Regher and revised by Xuejun Yang (stack.pl) that I hacked a bit to have it working correctly for GCC 4.3.0. It takes a .elf file as input and explores all the possible execution paths to return the maximum stack usage, taking into account stack usage by all routines running under interrupts. It also finds recursion (yet another fun way to break the stack).

It needs some tweaking from a compiler version to another since it locates stack usage by looking at patterns in the (dis)assembly code: if the generated code changes regarding stack usage, the script must be fixed. Since I stick with 4.3.0 at the moment, that's why the script is said to work with this version of avr-gcc.

Current targets are atmega64/1280/1281 & at90can128 and it's easy to add new ones (a target only defines memory & vector sizes). When I'm about to release some software, I now always check the elf file with this script, it has already helped me find & kill nasty bugs.

I periodically write about this tool here, and usually nobody cares about it.  So I try one more time, maybe I'll get more luck in 2010 ;-) Next try in 2011 if I see again people running after stack overflow bugs...

I can send the script to whoever wants it!

    Bernard

Dave Hylands wrote:

Hi Han,

On Tue, Feb 2, 2010 at 4:57 AM, Han Hoekstra
<address@hidden> wrote:
  

However, what I don't understand is that the while loop does not cause some
stack overflow, because I have decreased the array to be only a single
element, so app_TXIncomming is always 0, so the while loop should therefore
never loop.
    

Since the code size changes, lots of things that are stored on the
stack will also change (i.e. return addresses, addresses of global
variables etc). So the content of uninitialized variable may change as
well.

It's also possible to have a stack overwrite which doesn't affect all
bytes of the stack.

For example, let's suppose I declared a local (i.e. stack variable)

char buf[20];

And the last two bytes happened to line up with your 2 checker bytes.
If you never actually wrote to those bytes (maybe you only use the
first 10 bytes of buf), you still have a stack overflow, but not one
that is detected.

Changing the code size will cause the location of your checker bytes
to also change, and that may be enough to have it now collide.

You may wish to try filling all of the stack space with a fill byte,
and then checking to see how many fill bytes are untouched. It still
suffers from the problem I mentioned above, but it can often tell you
if you're getting close to filling the stack.