[LLVMdev] LLVM Archive Format Extension Proposal

[Michael Spencer]

On Mon, Dec 3, 2012 at 2:08 PM, Relph, Richard <Richard.Relph at amd.com> wrote:
> On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote:
>
>> On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>>
>>> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is
>>> capable of replacing it. The llvm tools that don't write archives
>>> files have already been switched over to it. Object/Archive already
>>> supports MemoryBuffer as a source for the data.
>>
>> I had meant to ask in my email about the apparent duplication of Archive in Bitcode and Object libs… Good to know. Since ranlib currently uses Bitcode, that's what I've been focusing on, but I had noticed the Object/Archive.h.
>
> Michael,
>     I understand and agree that having 2 Archive implementations is something that should be fixed. Do you have a rough idea about when you might do the unification?
>     Also, why unify around the Object/Archive implementation instead of the Bitcode/Archive implementation? What can the Object/Archive implementation "do" that can't be done with the Bitcode implementation?
>     I ask because after looking at Archive in Object and Archive in Bitcode, the Archive in Bitcode seems much better documented than the Archive in Object, and feels (at least to me at first glance) like a somewhat better model of what Archives are. And as you've already noted, Object/Archive can't do writes...
>
> Richard

I wrote Object/Archive for a couple reasons. The main reason was
performance. Bitcode/Archive parses the entire archive file up front
including the symbol table. Object/Archive does it lazily and uses
much less memory. The other reason is that Bitcode/Archive is heavily
focused on bitcode files. It even requires an LLVMContext to
construct. This is was not optimal for my object file needs.

- Michael Spencer