llvm dev - Sep 2013 - [LLVMdev] llvm-ar does not generates symbol table for contained bitcode files

Hi,

The behavior of llvm-ar appears to have changed such that the archive symbol
table no longer contains symbols contained within bitcode modules in the
archive. This behavior appears to have been changed with revision 184083 when
the internal implementation of llvm-ar was changed from lib/Archive/Archive.cpp
to lib/object/Archive.cpp. This seems to occur because
ObjectFile::createObjectFile() does not support creating objects of bitcode type
and thus llvm-ar cannot read them to retrieve the symbol information.

Is there a plan to add support back to llvm-ar to generate symbol table
information when archiving bitcode files?

Thanks,
 Jason

Steps to reproduce:
Create repro.c with the following contents:
const char* symbol = "Hello, World!";

Create archive containing llvm bitcode files (no symbol table created):
clang -emit-llvm -c -o repro.bc repro.c
llvm-ar rs repro.a repro.bc

Create archive containing object files (symbol table is created):
clang -c -o repro.o repro.c
llvm-ar rs repro.a repro.o


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/4a9de916/attachment.html>

On 19 September 2013 11:59, Jason Holajter <jholajter at arxan.com>
wrote:
> Hi,
>
> The behavior of llvm-ar appears to have changed such that the archive
symbol
> table no longer contains symbols contained within bitcode modules in the
> archive. This behavior appears to have been changed with revision 184083
> when the internal implementation of llvm-ar was changed from
> lib/Archive/Archive.cpp to lib/object/Archive.cpp. This seems to occur
> because ObjectFile::createObjectFile() does not support creating objects of
> bitcode type and thus llvm-ar cannot read them to retrieve the symbol
> information.
>
> Is there a plan to add support back to llvm-ar to generate symbol table
> information when archiving bitcode files?
Yes. I am sorry for the current state. Support for bitcode format will
be added back. The will be a few differences from before:

* It will use a "standard" symbol table instead of having a LLVM only
symbol table.
* The final name will be used. So on MachO you will see _foo, not foo.

In summary, the bitcode files in the .a archive will behave much more
like regular object files, making better suited for LTO.

Cheers,
Rafael

Hi Rafael,

Thank you for the response. The updated behavior to match the standard
symbol table makes sense.

Do you have any estimate for when the behavior describe below might be
implemented? 

Thanks,
 Jason 

On 9/30/13 3:57 PM, "Rafael Espíndola" <rafael.espindola at
gmail.com> wrote:
>On 19 September 2013 11:59, Jason Holajter <jholajter at arxan.com>
wrote:
>> Hi,
>>
>> The behavior of llvm-ar appears to have changed such that the archive
>>symbol
>> table no longer contains symbols contained within bitcode modules in
the
>> archive. This behavior appears to have been changed with revision
184083
>> when the internal implementation of llvm-ar was changed from
>> lib/Archive/Archive.cpp to lib/object/Archive.cpp. This seems to occur
>> because ObjectFile::createObjectFile() does not support creating
>>objects of
>> bitcode type and thus llvm-ar cannot read them to retrieve the symbol
>> information.
>>
>> Is there a plan to add support back to llvm-ar to generate symbol table
>> information when archiving bitcode files?
>
>Yes. I am sorry for the current state. Support for bitcode format will
>be added back. The will be a few differences from before:
>
>* It will use a "standard" symbol table instead of having a LLVM
only
>symbol table.
>* The final name will be used. So on MachO you will see _foo, not foo.
>
>In summary, the bitcode files in the .a archive will behave much more
>like regular object files, making better suited for LTO.
>
>Cheers,
>Rafael