> 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 <mailto:cfe-commits@lists.llvm.org>> wrote: > > > On Mar 29, 2016, at 12:00 PM, Joerg Sonnenberger <jo...@britannica.bec.de > > <mailto: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. > > & 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. > 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. Note that we currently also accept a -gused option which according to the driver code is supposed to be the opposite of -gfull. 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. -- 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 <mailto:cfe-commits@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > <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
