[LLVMdev] [LLVM] What has happened to LLVM bitcode archive support?

[Daniel Liew]

> We are going this way, yes.

You've confused me a bit here ( maybe I was being too vague )

Okay so I understand thst the old LLVM specific archive format is now gone.

However it seems you are allowing LLVM bitcode files ( I assume that's what
you mean by "IL" - does that stand for "intermediate language"? It's not in
[1] ) to be placed inside the more standard archive format understood by
GNU ar and nm.

Therefore LLVM is still supporting runtime libraries that consist of llvm
bitcode files (even if the format is now different)

For example, I can build a runtime library (e.g. a simple C library) as a
collection of bitcode modules and place them in an archive using the latest
llvm-ar ( I realise that currently the archive's symbol table will be
missing symbols from the bitcode files).

> I
> posted what I think is the last big patch for review (making the
> Mangler not depend on target). With that in things should move fairly
> quickly to have llvm-ar just work with IL files and with that
> lib/Object should have the features you need.

Okay. Could you please clarify? Do you mean?

- Future changes to lib/Object will let me read the symbols in an archive
so I can implement my own ( primitive bitcode only ) linking?

Or

- Future changes to lib/Object will  implement llvm module linking for me?

I suspect you meant the first. If so, is the intention that if someone
needs to link an in memory LLVM bitcode module to an archive of bitcode
modules ( produced by the new llvm-ar or at with llvmLTO wrapper to ar)
then they should use the API of lld? Does that API exist now? I took a look
at the lld source code and I couldn't find any methods that returned
llvm::Module so I assumed it wasn't possible.

Thanks,
Dan Liew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131220/c65f6e54/attachment.html>