[cfe-dev] Optionally suppress debug info for inlined calls?

[Eric Christopher]

On Mon, Dec 2, 2013 at 10:50 AM, Philip Reames
<listmail at philipreames.com> wrote:
> On 11/25/13 4:28 PM, Robinson, Paul wrote:
>>
>>
>>> If we could find a good heuristic
>>> for "trivial inline functions" (maybe a function with a single setter
>>> or return) and use that as our signal for "don't bother emitting debug
>>> info for this" maybe that would be good. That would still provide the
>>> size wins with the benefit that it might be beneficial to a broader
>>> range of users.
>>
>> How about "any indication in the source that the programmer wanted it
>> inlined."  That is: (i) method defined inside the class declaration;
>> (ii) 'inline' keyword; (iii) an attribute that means "inline this."
>> All of these are indications that the programmer wanted the function
>> inlined, and if the programmer then builds the program using the
>> proposed -gno-inlined-scopes feature, it should not be shocking to
>> anyone that these inlined functions don't have debug info.  (Sorry to
>> be proposing something that isn't shocking; it's all I got.)
>
> Speaking for only for myself, I would strongly oppose this proposal. This
> proposal would require that anyone who wanted to step inside any inline
> function would be required to modify the source code and recompile.  Maybe
> I've just spent too much time debugging nasty timing related bugs, but I
> view that as an unacceptable debugging experience.
>
> Just to note, I do like the idea of being able to specify certain functions
> as "uninteresting" to the debugger.  I'd lean towards having this be a
> debugger flag, not a compiler flag, but if the only efficient implementation
> was at the compiler level, I could probably live with that.  It's the
> combination of "inline hint" and "no debug info hint" that I'm objecting to.
>

FWIW I agree with this in principle. I think the what to show and what
not to show is largely up to the debugger and that the job of the
compiler is to put out information that would be useful. The only
reason I mentioned "always_inline, nodebug" for those functions is
that it's something that could be implemented for gcc compatibility
and exists as a mechanic. I think for Paul he should work with his
debugger team on how to get them to show what's interesting as
something user visible.

-eric