<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Apr 5, 2012, at 10:24 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
<br>
> Hi!<br>
><br>
> Currently Clang "-g" flag emits full debug info, which is fine for debugging, but increases the binary size significantly.<br>
> It may be useful to produce less debug info, that is still enough for collecting nice stack traces with file names and line numbers,<br>
> but would introduce less overhead. Cary Coutant made a patch which does this for GCC (it didn't hit trunk yet) -<br>
> reduces debug info to only descriptions of functions, extern variables, line number tables and inlined subroutine info<br>
> by setting "-gmlt" ("minimum line table") or "-g1" flags.<br>
> (See this patch at <a href="http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html" target="_blank">http://old.nabble.com/-patch--Add-new--gmlt-option-for-min.-debug-info-with-line-tables-(issue4440072)-td31482851.html</a><br>

> or <a href="http://codereview.appspot.com/4440072" target="_blank">http://codereview.appspot.com/4440072</a>). This patch is used in Google for about 2 years already.<br>
><br>
> I get the following binary sizes of 483.xalancbmk benchmark from SPEC 2006 (clang from trunk vs. gcc 4.6.x with Google patches):<br>
> 11026073 Xalan_base.clang_O0<br>
> 45882529 Xalan_base.clang_O0_g<br>
> 11079688 Xalan_base.gcc_O0<br>
> <a href="tel:16437776" value="+4916437776">16437776</a> Xalan_base.gcc_O0_gmlt<br>
> 54221056 Xalan_base.gcc_O0_g<br>
><br>
> WDYT of implementing similar option in Clang? Clearly, there are two options:<br>
> 1. Don't modify Clang codegen, but instead erase all the extra debug info by LLVM (pro - there actually is StripDebugInfo pass already, but it's very short and easy,<br>
> and would have to be patched a lot).<br>
> 2. Emit less information in Clang. We're also quite interested if this may reduce the compilation time as well.<br>
> Which approach looks better in your opinion? I'd like to start working on that enhancement, but certainly would be happy to hear some advice beforehand.<br>
<br>
</div></div>I was holding off trying to come up with ways to give advice and I've only come up with a couple. Unfortunately a lot of how things work is tied into the recursive route that we take. I think it may require a bit of an overhaul for how we end up limiting debug information, but I'm very interested in seeing it. If there's anything I can do to help let me know.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Eric,</div><div><br></div><div>I've uploaded an early draft (though, barely tested) at <a href="http://codereview.appspot.com/6015050/">http://codereview.appspot.com/6015050/</a>, could you PTAL?</div>
<div>The debug info is printed all around lib/CodeGen sources, so the patch looks quite messy - I had to cut off pieces of code that emit</div><div>different kinds of debug info about variables and types here and there. I've left a bunch of asserts in the patch inside</div>
<div>the functions that presumably should not be called (yeah, all this is so fragile). The patch description contains some comments about the goal</div><div>as well.</div><div><br></div><div>Do you think that this direction is fine in general?</div>
<div>With flag -gline-tables-only enabled, I get about 1.5x binary size increase on a large test.</div><div>I'm able to see stack traces with line numbers in gdb on a microtest as well.</div><div><br></div><div>-- </div>
</div><div>Alexey Samsonov, MSK</div>