On Fri, Apr 1, 2016 at 10:54 AM, Adrian Prantl <apra...@apple.com> wrote:
> > On Mar 31, 2016, at 5:35 PM, David Blaikie <dblai...@gmail.com> wrote: > > > > 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. > > > 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) > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
