<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 5:11 AM, Dave Bozier <span dir="ltr"><<a href="mailto:seifsta@gmail.com" target="_blank">seifsta@gmail.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 dir="ltr"><span class=""><span style="font-size:12.8000001907349px">> Are you sure about the additional I/O? With native symtab, existing tools just need to read those, while plugin based approach needs to read bit code section to feedback symbols to the tool.</span><br><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">The additional I/O will be quite big if you are going to emit the full symbol table. Looking at some of our real world links the symbol table and string tables of all the inputs seen by the linker add up to about 50 - 100mb.</span></div></div></blockquote><div>(resent as the previous message got bounced)</div><div><br></div><div><div>There is no need for emitting the full symtab. I checked the overhead with a huge internal C++ source. The overhead of symtab + str table compared with byte code with debug is about 3%.</div><div><br></div><div>More importantly, there is plan to use the symtab also for thinLTO indexing purpose, which makes the space usage completely 'unwasted'. That gets into the details which will follow when the patches are in (with design docs).</div></div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div></div><br></div></div>