[PATCH] D18565: Implement an "I'm dtrace, please retain all debug types" option.

[David Blaikie via cfe-commits]

On Fri, Apr 1, 2016 at 10:54 AM, Adrian Prantl <aprantl at apple.com> wrote:

>
> On Mar 31, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Wed, Mar 30, 2016 at 10:49 AM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Mar 29, 2016, at 10:06 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Tue, Mar 29, 2016 at 12:03 PM, Adrian Prantl via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>>
>>>
>>> > On Mar 29, 2016, at 12:00 PM, Joerg Sonnenberger <
>>> joerg at britannica.bec.de> wrote:
>>> >
>>> > On Tue, Mar 29, 2016 at 06:47:24PM +0000, Adrian Prantl via
>>> cfe-commits wrote:
>>> >> This code in this patch listens to the driver option -gfull, and
>>> lowers it to the new cc1 option -debug-retain-types (1).
>>> >> When -debug-retain-types is present, CGDebugInfo will retain every(2)
>>> type it creates.
>>> >
>>> > Is there a good reason for calling it -gfull? I would find something
>>> > -gall-types or -gretain-all-types to make a lot more sense. This should
>>> > be orthogonal to other options like providing only line tables?
>>>
>>> My thinking was this:
>>> The driver already supports -gfull, but it doesn’t do anything.
>>> This patch can be considered a first step towards making -gfull behave
>>> as expected.
>>> Eventually it should emit debug info for *all* types.
>>>
>>
>> Seems somewhat problematic to half implement it, though. (admittedly
>> we're just silently ignoring it right now)
>>
>>
>> I don’t think this is problematic at all. This is incremental development.
>>
>
> It strikes me as a strange increment. Implementing full -gfull doesn't
> seem like it would take much time to implement, etc.
>
>>
>> & is 'real' -gfull what dtrace really wants? (seems it isn't - since
>> clang's never really implemented it?)
>>
>>
>> Admitted, ‘real' -gfull is probably more than it absolutely needs.
>>
>
> If just retaining referenced types is all it needs, yeah, it seems -gfull
> would be rather beyond that.
>
>
>>
>> Emitting all types referenced by used (even if later optimized away) code
>> seems like the thing? -greferenced? or maybe a -f flag? Not sure.
>>
>>
>> I don’t see a compelling case for adding another driver option to the
>> already confusing zoo of existing driver options.
>>
>
> My point is I think a -gfull that does something other than full would
> possibly be more confusing than not.
>
>
> Point taken. Let’s surface this under a separate option instead. We can
> call it “-greferenced” to fit between -gfull and -gused.
>

After seeing that -gfull/-gused are Darwin-only extensions in GCC, and if
we're introducing a new one anyway - should we be compatible with those
(that don't do anything in Clang anyway), or use something more like the -f
syntax used in GCC? It seems like we may want to avoid more -gX options
because they're often orthogonal (Google's recently had trouble with
-gsplit-dwarf + -gmlt, for example (build system gets confused when you
remove the output file it asked for... ))

- Dave


>
> thanks,
> adrian
>
>
>
>> Note that we currently also accept a -gused option which according to the
>> driver code is supposed to be the opposite of -gfull.
>>
>
> Are -gused/-gfull meant to toggle each other?
>
> Huh, seems they're not general GCC flags, they're Darwin things - I didn't
> know that.
>
> Looks like GCC usually spells this -f[no-]eliminate-unused-debug-types.
> But doesn't seem to have an intermediate version that would be what you're
> going for.
>
>
>> Adding a -greferenced option IMO will only make this more confusion
>> instead of helping.
>> My suggestion is to have -gfull (also) activate -debug-retain-types. In
>> the somewhat hypothetical scenario that someone implements a more
>> comprehensive version of -gfull we should revisit this and analyze whether
>> the resulting debug information is really too large to be practical, and if
>> we conclude that this is a problem, we can still decide to expose
>> -debug-retain-types to the driver with a new separate option.
>>
>
> I would be concerned about breaking other existing users that may grow
> once we support the flag. (& perhaps inconsistency between GCC and Clang,
> but inconsistency already exists there of course)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160401/3ff2d745/attachment.html>