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

[David Blaikie via cfe-commits]

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.


> 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)

- David


>
> -- adrian
>
>
>
>>
>> > Joerg
>> >
>> > PS: Slightly related side question, do we have any tools for extracting
>> > a given list of types for retaining? Either by name or global variable
>> > expression.
>>
>> Extract them from where? Can you give an example?
>>
>> -- adrian
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160331/ebccce2d/attachment-0001.html>