Re: debugging inline functions

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

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

It's interesting that you bring this up.  With my current (still
deactivated, but installed) patch, I believe that *incorrect*
line-number information will be emitted for inlined functions.  (In
particular, nothing tells the back-end what file the inlined function
is in, so I expect that stepping into the code for an inlined function
will result in seeing the file of the caller with the line-numbers of
the callee.)  That's just plain wrong, and I'm going to fix it.

Also, there's no debugging information emitted for local variables
(including parameters) in an inlined function.

I had intended to:

  o Fix the filename/linenumber issue to that the code for an inlined
    function would have the file/name corresponding to the location
    of the inlined function.

  o Make the parameters/variables of the callee appear as locals in
    the caller.

The back-end won't know that the callee was ever a separate function,
so I would assume that in GDB you will just see the stack-trace
indicating you are in the caller, rather than the callee, even though
the source display will show the callee.

To me, that makes sense.

Is that OK with everyone?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com