debugging inline functions

[Per Bothner <per at bothner dot com>]

[I'm following up on a message Mark sent to gcc-patches, with the
subject "C++ PATCH to defer RTL generation for inlines", but since
this is more about design issues, and is gdb-related, I changed
the mailing lists.]

Mark Mitchell <mark@codesourcery.com> writes:

> Next will be to get debugging information correct for the inlined
> functions; at that point, I'll turn this stuff on by default.

I hope "getting debugging information correct" means doing better than
we traditionally have for inlined functions, which have been almost
impossible to use.  The problem is that if we're inside an inlined
function, Gdb is unable to show in its stack trace the *actual*
function, or rather the line number information is inconsistent
with the call stack information.  The bug is partly Gdb, partly the stabs
debug format, and partly the emitted debugging information.  Because
stabs does have a well-defined way to specify inlining, and Dwarf2 does,
it might be reasonable to concentrate on getting Dwarf2 debugging right.

I guess we should first define what "getting it right" means.  To me,
that means be able to show stack containing a mix on inlined and
regular calls in a way that makes sense.  Each stack frame must show
a consistent line number, function name, and parameter list.  Showing
a stack frame with the line number of the inlined function but with
the function name and arguments of its caller is just plain confusing,
as well as a pain to work with.

I see two choices:  Either we *drop* line numbers from inlined code
(i.e. pretend the entire inlined function is like a macro that
appears in the call site line), or we do it *right*.  The current
half-assed approach is worse than nothing; it makes it very difficult
to debug optimized C++ code.

The right approach is to add "pseudo-stack-frames" for the inlined
functions.  I vaguely remember the Mips debugger had pseudo-frames for
lexical blocks, not just for entire functions.  That may be overkill
(though it allows you to see "shadowed" variables), but once you have
that, it is trivial to add pseudo-frames for inlined functions.

The stack frame for an inlined function should should ideally show the
line (and column) number in the lined function, the name of the
inlined function, and the parameter list.  Gettting the parameter
values is easy: We must generate stabs for:

        inline int foo(int i)   // line 100
        {                       // line 101
          int k = 2 * i;        // line 102
          return k + i;         // line 103
        }                       // line 104
        ...
        foo (10)                // line 200
as if the code was:
        {
          int i = 10;           // line 200
          {
            int k = 2 * i;      // line 102
            return k + i;       // line 103
          }
        }

What we need to do is also annotate the block that defines the inlined `i'
that this is an inlined procedure, and that `i' is one of the parameters.
With that information, we can generate a correct stack trace.

So the task for Gcc is to generate debug information that allows
this information to be extract.  For dwarf2, I assume there is a spec
we can follow.  For stabs, we can add a descriptive string (such as "foo(i)")
to the "begin block" symbol.

Maybe once Gcc generates the correct debug information, it may be
possible to motivate the Gdb people to do the right thing with it ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/