<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 10:54 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Mar 31, 2016, at 5:35 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 30, 2016 at 10:49 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Mar 29, 2016, at 10:06 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, Mar 29, 2016 at 12:03 PM, Adrian Prantl via cfe-commits<span> </span><span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>> On Mar 29, 2016, at 12:00 PM, Joerg Sonnenberger <<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>> wrote:<br>><br>> On Tue, Mar 29, 2016 at 06:47:24PM +0000, Adrian Prantl via cfe-commits wrote:<br>>> This code in this patch listens to the driver option -gfull, and lowers it to the new cc1 option -debug-retain-types (1).<br>>> When -debug-retain-types is present, CGDebugInfo will retain every(2) type it creates.<br>><br>> Is there a good reason for calling it -gfull? I would find something<br>> -gall-types or -gretain-all-types to make a lot more sense. This should<br>> be orthogonal to other options like providing only line tables?<br><br></span>My thinking was this:<br>The driver already supports -gfull, but it doesn’t do anything.<br>This patch can be considered a first step towards making -gfull behave as expected.<br>Eventually it should emit debug info for *all* types.<br></blockquote><div><br></div><div>Seems somewhat problematic to half implement it, though. (admittedly we're just silently ignoring it right now)<br></div></div></div></blockquote><div><br></div></span><div>I don’t think this is problematic at all. This is incremental development.</div></div></div></blockquote><div><br></div><div>It strikes me as a strange increment. Implementing full -gfull doesn't seem like it would take much time to implement, etc.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br>& is 'real' -gfull what dtrace really wants? (seems it isn't - since clang's never really implemented it?)<br></div></div></div></blockquote><div><br></div></span><div>Admitted, ‘real' -gfull is probably more than it absolutely needs.</div></div></div></blockquote><div><br></div><div>If just retaining referenced types is all it needs, yeah, it seems -gfull would be rather beyond that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Emitting all types referenced by used (even if later optimized away) code seems like the thing? -greferenced? or maybe a -f flag? Not sure.</div></div></div></blockquote><div><br></div></span><div>I don’t see a compelling case for adding another driver option to the already confusing zoo of existing driver options.</div></div></div></blockquote><div><br></div><div>My point is I think a -gfull that does something other than full would possibly be more confusing than not.</div></div></div></div></div></blockquote><div><br></div></span><div>Point taken. Let’s surface this under a separate option instead. We can call it “-greferenced” to fit between -gfull and -gused.</div></div></div></blockquote><div><br></div><div>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... ))<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div>thanks,</div><div>adrian<span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div> Note that we currently also accept a -gused option which according to the driver code is supposed to be the opposite of -gfull. </div></div></div></blockquote><div><br></div><div>Are -gused/-gfull meant to toggle each other?<br><br>Huh, seems they're not general GCC flags, they're Darwin things - I didn't know that.<br><br>Looks like GCC usually spells this <span style="font-family:monospace;font-size:inherit">-f[no-]eliminate-unused-debug-types. But doesn't seem to have an intermediate version that would be what you're going for.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Adding a -greferenced option IMO will only make this more confusion instead of helping.</div><div>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.</div></div></div></blockquote><div><br></div><div>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)<br></div></div></div></div></div></blockquote><div><br></div><div><br></div></span></div></div></blockquote></div><br></div></div>