[cfe-dev] Optionally suppress debug info for inlined calls?
listmail at philipreames.com
Mon Dec 2 11:05:55 PST 2013
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.
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
More information about the cfe-dev