[sdcc-devel] [ sdcc-Bugs-1653651 ] sdcdb incorrectly reports "Stack underflow"

[SourceForge.net <no...@so...>]

Bugs item #1653651, was opened at 2007-02-06 23:34
Message generated for change (Comment added) made by borutr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1653651&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Debugger
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Frieder Ferlemann (frief)
Assigned to: Nobody/Anonymous (nobody)
Summary: sdcdb incorrectly reports "Stack underflow"

Initial Comment:
As reported by arkady (larytet) in the Open Discussion forum:

http://sourceforge.net/forum/forum.php?thread_id=1651244&forum_id=1864

sdcdb reports "Stack underflow" when debugging the straightforward code:

--------8<------------------------------------------
static unsigned char idleTask(unsigned char context) 
{ 
  context++; 
  return context; 
} 
 
static void mainLoop() 
{ 
  unsigned char context = 0; 
  while (1) 
    { 
      context = idleTask(context); 
    } 
} 
 
void main() 
{ 
  mainLoop(); 
} 
-------->8------------------------------------------

(More details in the above mentioned thread)


----------------------------------------------------------------------

>Comment By: Borut Ražem (borutr)
Date: 2011-01-09 11:36

Message:
> Btw. why do we use a double dash in --fverbose-asm?

Doesn't sdcc use duble dash for all long (non-one-letter) options?

----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2011-01-09 11:02

Message:
In this case it was the second example about dead code elimination that
triggered the bug as it jumps back to the start of the infinite loop. The
following RET was removed and the debugger thinks the JUMP is the end of
the function and pops its household stack.

Also another optimization could cause it:
JUMP to RET => RET

And when sibling optimization as gcc calls it replaces the final RET with
a JUMP another optimization can also cause it:
JUMP to JUMP => JUMP
as it does not reach the last generated instruction of the function.

So disabling either of these could fix the problem. Since sibling
optimization is usually surprising and sometimes annoying while debugging I
considered this the best candidate to be disabled.

>From the little I read about sibling optimization I think gcc tries to do
a lot more than what our peephole optimizer can do or does. Ours is just
one special case of a void returning function without stack frame for
locals.

All in all I think -foptimize-sibling-calls does not quite describe what's
happening. I think I'll go for -foptimize-return and -fno-optimize-return.
Btw. why do we use a double dash in --fverbose-asm?

Maarten

----------------------------------------------------------------------

Comment By: Patryk (patryks)
Date: 2011-01-09 02:33

Message:
I suggest 3rd option in Borut's version - optimization enabled by default
in non-debug, disabled by default in debug, but switchable. Disabled
inreases stack usage, and some applications in 8051 small memory model are
written using every possible RAM byte, with stack usage analyzed for
deepest branch.

----------------------------------------------------------------------

Comment By: Borut Ražem (borutr)
Date: 2011-01-08 18:07

Message:
I think the 2nd option is the right one. Other compilers also disable (or
at least discourage) some optimizations when debugging is enabled.

The 3rd option is also not a bad idea, as an addition to the 2nd one: in
non-debug mode the return optimization will be enabled by default, in debug
mode it will be disabled, while the new command line option will give a
possibility to toggle it. I took a quick look to the gcc optimization
options and I found -foptimize-sibling-calls, which I think does the job.
So in sdcc it would be --foptimize-sibling-calls and
--fno-optimize-sibling-calls.

Whatever will be implemented it should also be documented.

Borut

----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2011-01-08 11:31

Message:
Hi,

I want to fix this by disabling several return-optimizations in the
peephole optimizer. Like:
CALL + RET => JUMP
JUMP + RET => JUMP
When functions have only one exit-point and this RET is the last
instruction then the debugger can keep track.

Now the question is: how?
1. Just remove them
2. disable them when --debug is used
3. en/disable them with a new command line option

Any suggestions anyone?

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1653651&group_id=599