[llvm] r241721 - Start adding support for writing archives in BSD format.

[Kevin Enderby]

> On Jul 9, 2015, at 5:39 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 8 July 2015 at 21:02, Kevin Enderby <enderby at apple.com> wrote:
>> Hi Rafael,
>> 
>> I had been working on the same support and noticed your changes today when I updated just now.  I am heading out for the day but haven’t resolved my conflicts.  I have the support for the symbol table done but if you get to that that and want to use yours that is fine.
>> 
>> I my version also had a separate darwin format which is BSD with 8 byte alignment.  But if you see no need for that that is fine too.
> 
> So, the situation with darwin native tools is a bit odd. It looks like
> ar proper will add some padding to the name, but fails to align the
> member to 8 bytes.

Yes the darwin ar(1) tool is not great and not what is used in the end to build static archives.  libtool(1), also as ranlib(1) via a symlink, does all the right things.  Including dealing with fat files.

> 
> Ranlib instead of changing the name with null padding pads the member
> itself with '\n' to the end.

What it is doing is getting the start of the member contents to 8 byte alignment by padding the name (4 bytes needed for the fact that struct ar_hdr is only a multiple of 4), then null pads the name to get to 8 byte alignment.

If the member itself is not a multiple of 8 bytes (which should never happen with the darwin tools), it will actually change the size of the member and pad with ‘\n’.  As the original ar(1) pads non-even sized members with a single ‘\n’.  And yes people have complained about this with the darwin tools.

Whole thing is a bit of a mess as ar(5) format was never designed to have its members aligned.  So I did the best I could do working with padding the name and forcing the darwin tools to alway build 8 byte multiple object files.

> 
> My idea was to always pad the name with nulls so that we have members
> that are 8 byte aligned and we never modify files put in the archive.

That get the member to start on an 8-byte boundary, but its size is not a multiple of 8 bytes you still have to deal with that.  Again the only way I could think of dealing with this is to change the member size.  If objects always have sizes that are 8-byte multiples it never matters.  If not it makes a mess of things.   That is why we use libtool(1) to create “static libraries” and not ar(1) to create “archive files”.  As we have stricter rules on “static libraries” including no non-object files allowed in them, sized to 8 byte multiples, warns if there are no symbols in the table of contents, etc.

> I am probably half the way there to get __.SYMDEF out, if you don't
> mind I will finish that and add the sorted version as a follow up.

No problem.

> I will also be adding support for thin archives.

Not sure what "thin archives” are but I’ll watch for the diffs an help in any way I can.

>> Didn’t know I was duplicating your work.  Catch up with you tomorrow,
> 
> Oops, sorry about that. Do you hang out in #llvm? It is a good place
> to discuss what everyone is doing.

Yep I should do that.

> 
> Cheers,
> Rafael
> <t.patch>