On Wed, Mar 30, 2016 at 10:49 AM, Adrian Prantl <apra...@apple.com> wrote:
> > On Mar 29, 2016, at 10:06 PM, David Blaikie <dblai...@gmail.com> wrote: > > > > On Tue, Mar 29, 2016 at 12:03 PM, Adrian Prantl via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> >> > On Mar 29, 2016, at 12:00 PM, Joerg Sonnenberger < >> jo...@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@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
