This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: debugging inline functions

>>>>> "Per" == Per Bothner <> 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         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]