<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 3, 2014 at 5:35 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Fri, Jan 3, 2014 at 8:19 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>(As context, for me this is mostly about clang-format since I noticed AST and Sema code making it into its final binary, which I thought is a bit silly. This is also only about a few hundred kilobytes, so I'm happy with whatever outcome we arrive at. I consider this a minor cleanup and I'm not strongly arguing for anything.)</div>


<div><br></div><div>Chandler wrote:</div><div><div><div>> Linker dead stripping is only one of many ways dead stripping can and does occur. The used attribute is a much more stable way of ensuring that these debugging aids are available.</div>


<div><br></div></div><div>Oh? For example? (I'm curious, I didn't know this.)</div></div></blockquote><div><br></div></div><div>LTO, archive member dropping (hopefully not relevant here), and some linkers that do minimal dead stripping by default.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div>> Similarly, I really want to be able to call dump methods from a Release+Asserts binary. The +Asserts means that the increased binary size shouldn't be a problem, and this can be a huge help when debugging bootstrap miscompiles and in-the-wild crashers.<br>

</div>
</div></div><div><br></div><div>You mostly diagnose crashes of clang in the wild, right? That's built without dead stripping anyways.</div></blockquote><div><br></div></div><div>Not exclusively, no.</div><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I tend to build everything in Release+Asserts, since I use trunk and want the internal sanity checks. I'm fine with the performance and size impact this has, but I don't agree that +Asserts necessarily implies "for debugging". (Again, I'm not strongly arguing for this, I'm just describing my perspective.)<br>

</div></blockquote></div></div><br>Sure. We could completely separate out the "asserts" knob from the "dumping" knob. We already enable turning on dumping without turning on asserts. Historically, asserts have carried much more binary size and other impact than the dumping methods. There may be a library layering issue if you're seeing dump methods drag in large amounts of binary size into clang-format.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">My preference is for fewer knobs in general, but if there really are all four states here (+asserts +dumping, -asserts -dumping, +asserts -dumping, -asserts +dumping) then we can support that I guess. I just don't know of any real demand.</div>

</div>
</blockquote></div><br></div><div class="gmail_extra">I don't think this is worth adding another knob for.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Not doing dead stripping in debug builds is something that might make sense anyway though (if anyone disagrees, please let me know!), and once that's done maybe not all dump methods would need to be marked used in release builds (only the ones that folks consider so useful that they need them in their release+asserts builds in addition to in debug builds)?</div>
</div>