Re: tail call optimization vs. debugging

Re: tail call optimization vs. debugging

[Geert Bosch]

On Fri, 24 Mar 2000 14:24:04 -0800, Richard Henderson wrote:
  > 1. that tail call elimination be disabled/enabled by a particular command
  >    line option,
  This we will do, default on at -O2.

For many people it is quite important to be able to do meaningful
debugging on optimized code. For most of my compiler work, this
combination is essential for debugging as I would loose too much
time using a slow compiler, not to mention bootstrap problems
that only occur when using optimization. The GCC/GDB combination 
always has been reasonably good at handling this, although indeed 
instruction scheduling can make things like single-stepping impractical.

One of the main things that IMO needs to be preserved, even when it
would mean loosing some optimizations at -O2, is being able to reliably
breakpoint on functions and get useful stack tracebacks with arguments.
If this cannot be guaranteed with tail-call optimizations on, I think it
should not be part of -O2. After all, wasn't this the reason why 
-fomit-frame-pointer isn't enabled at -O2?

Having yet-another-flag may seem an easy solution, but I'm not sure it 
is the right one. The issue is not being able to compile
a version of the program specially compiled to be debuggable, but to be 
able to debug a random program that was compiled with GCC using a common 
optimization level.

Now we have:
 -O 
 -O1 Optimize. [But keep compilation fast and make debugging give expected results]
 -O2 Optimize even more. [...] 
     [GCC also turns on] frame pointer elimination on machines 
     where doing so does not interfere with debugging. 
 -O3 Optimize yet more. [Also trade size for speed by inlining]
 -O0 Do not optimize. 
 -Os Optimize for size.

Richard, can you elaborate on what effect the new tail-call/sibcall optimizations
will have on debugging, and in particular on breakpointing functions and getting
tracebacks?

Here are a few yes/no debugging questions that popped up for me:
  - Will function breakpoints be hit by a tail call or sibcall? 
  - In recursive functions, will printing arguments show the argument values
    of the last (recursive) call?
  - Do cases where unbounded recursion (due to tail call optimizations)
    only show a few frames in a trace-back always use bounded stack space?

Regards,
   Geert

Re: tail call optimization vs. debugging

[Richard Henderson]

On Sat, Mar 25, 2000 at 12:18:25PM -0500, Geert Bosch wrote:
> Here are a few yes/no debugging questions that popped up for me:
>   - Will function breakpoints be hit by a tail call or sibcall? 

Yes.

>   - In recursive functions, will printing arguments show the argument values
>     of the last (recursive) call?

On pure tail calls, yes.  The new arguments get put exactly where
they should have been for a normal call.

With tail recursion (which we had before, but will trigger more often
now) I can only say "probably".  It's implemented with a goto internally,
so the optimizer has the chance to not put the new arguments in place.

>   - Do cases where unbounded recursion (due to tail call optimizations)
>     only show a few frames in a trace-back always use bounded stack space?

Eh?  If I understand the question correctly, of course.
How else could it be a tail call optimization?


r~

Re: tail call optimization vs. debugging

[Martin v. Loewis]

> One of the main things that IMO needs to be preserved, even when it
> would mean loosing some optimizations at -O2, is being able to
> reliably breakpoint on functions and get useful stack tracebacks
> with arguments.

Does this mean you don't want the compiler to support the inline
keyword? Because with inlining, you cannot set a break-point on an
inlined function, and get a useful stack backtrace with arguments
right now.

Martin

Re: tail call optimization vs. debugging

[Richard Henderson]

On Sat, Mar 25, 2000 at 04:09:25PM -0500, Geert Bosch wrote:
> Fortunately Richard has clarified this issue a bit, although
> it would be nice to force the compiler to put the arguments in place.

It'll be no worse than any other time the optimizer makes
a variable appear to contain incorrect values.


r~

Re: tail call optimization vs. debugging

[Geert Bosch]

On Sat, 25 Mar 2000 21:50:46 +0100, Martin v. Loewis wrote:
  Does this mean you don't want the compiler to support the inline
  keyword? Because with inlining, you cannot set a break-point on an
  inlined function, and get a useful stack backtrace with arguments
  right now.

This is a different case, as this only applies to functions explicitly
marked inline. The user can usually see this in the sources, and
will expect that some debugging functionality may be lost. 

In the case of tail call optimizations, this wouldn't be the case, and
the user might come to the wrong conclusion that the function has
not been called. 

Fortunately Richard has clarified this issue a bit, although
it would be nice to force the compiler to put the arguments in place.

Richard wrote:
  With tail recursion (which we had before, but will trigger more often
  now) I can only say "probably".  It's implemented with a goto internally,
  so the optimizer has the chance to not put the new arguments in place.

Re: tail call optimization vs. debugging

[Richard Henderson]

On Fri, Mar 24, 2000 at 09:38:31PM +0100, Bruno Haible wrote:
> Many GNU programs are compiled with "-O2 -g" by default, which has been
> up to now a good compromise between speed and ease of debugging.

That you think this is a clear indication that you do most
of your work on x86.  On alpha and other wide risc targets
the instruction scheduling turned on with -O2 makes debugging
quite a challenge most of the time. 

> 1. that tail call elimination be disabled/enabled by a particular command
>    line option,

This we will do, default on at -O2.

> 2. that this command line option be "-fomit-frame-pointer".

No.


r~

Re: tail call optimization vs. debugging

[Daniel Berlin+list.gcc]

Bruno Haible <haible@ilog.fr> writes:


> For each optimized tail call, in the debugger, there is a stack
>frame missing.
Given, AFAIK.

> Example:
>          A () { B (); }
>          B () { C (); }
>          C () { D (); ... }
> Here gdb will only display the stack frames of A and D. That is, the tail
> call elimination makes debugging very hard.

Maybe, i don't know yet.
> 
> Many GNU programs are compiled with "-O2 -g" by default, which has been
> up to now a good compromise between speed and ease of debugging.
> 
Sure.
> May I suggest:
> 
> 1. that tail call elimination be disabled/enabled by a particular command
>    line option,

Not my call.
> 
> 2. that this command line option be "-fomit-frame-pointer", which is the
>    other optimization which makes debugging impossible. Since -O2 does
>    not imply "-fomit-frame-pointer", "-O2 -g" would continue to produce
>    reasonably debuggable code.
Here's where i have a problem.
-fomit-frame-pointer does not make code undebuggable.
In the past it did have trouble, but it's had frame pointerless
debugging for over a year now, i believe.
When is the last time you tried to debug code with
-fomit-frame-pointer on?

--Dan

> 
> Bruno

tail call optimization vs. debugging

[Bruno Haible]

For each optimized tail call, in the debugger, there is a stack frame missing.
Example:
         A () { B (); }
         B () { C (); }
         C () { D (); ... }
Here gdb will only display the stack frames of A and D. That is, the tail
call elimination makes debugging very hard.

Many GNU programs are compiled with "-O2 -g" by default, which has been
up to now a good compromise between speed and ease of debugging.

May I suggest:

1. that tail call elimination be disabled/enabled by a particular command
   line option,

2. that this command line option be "-fomit-frame-pointer", which is the
   other optimization which makes debugging impossible. Since -O2 does
   not imply "-fomit-frame-pointer", "-O2 -g" would continue to produce
   reasonably debuggable code.

Bruno