From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Geert Bosch" <bosch@gnat.com>
To: "Bruno Haible" <haible@ilog.fr>, "Richard Henderson" <rth@cygnus.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: tail call optimization vs. debugging
Date: Sat, 25 Mar 2000 09:17:00 -0000
Message-id: <20000325171727.D8EFD34D80@nile.gnat.com>
X-SW-Source: 2000-03/msg00671.html

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