<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 1:21 PM, Rafael Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank" class="cremed">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":akc" style="overflow:hidden">Change llvm-ar to use lib/Object.<br>
<br>
This fixes two bugs is lib/Object that the use in llvm-ar found:<br>
* In OS X created archives, the name can be padded with nulls. Strip them.<br>
* In the constructor, remember the first non special member and use that in<br>
  begin_children. This makes sure we skip all special members, not just the<br>
  first one.<br>
<br>
The change to llvm-ar itself consist of<br>
* Using lib/Object for reading archives instead of ArchiveReader.cpp.<br>
* Writing the modified archive directly, instead of creating an in memory<br>
  representation.<br>
<br>
The old Archive library was way more general than what is needed, as can<br>
be seen by the diffstat of this patch.<br>
<br>
Having llvm-ar using lib/Object now opens the way for creating regular symbol<br>
tables for both native objects and bitcode files so that we can use those<br>
archives for LTO.</div></blockquote></div><br>This is awesome. =D</div><div class="gmail_extra"><br></div><div class="gmail_extra">Any chance you have performance numbers for binutils 'ar', old llvm-ar, and lib/Object llvm-ar? I'd like to make sure we can use this new fancy 'ar' tool without any issues even in non-LTO cases.</div>
</div>