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

[Philip Reames]

On 12/2/13 10:59 AM, Eric Christopher wrote:
> 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
Just to clarify slightly, I have no problem with a compiler flag that is 
off by default.  I simply wouldn't use it.  If the patch is isolated (or 
could be refactored to be so), I would have no problem with the 
heuristic being in tree provided it was off by default. Nor do I oppose 
some (separate) function attribute (as Eric mentions).  I could even see 
the later as something I might potentially use at some point - with 
caution.

Philip