[patch][rfc] Handling inline assembly in IRObjectFile

[Rafael Espíndola]

When using plugins with gold or ld64 we are able to handle symbols
being defined and used from inline assembly. This is critical for lld
which needs the information for GC (I think) but is also handy for
gold since it allows it to fetch archive members correctly and avoids
us internalizing globals in one file that are used from assembly in
another.

There a few options on how to handle this in the llvm tools world, all
with some undesirabilities.

One options would be simply: don't do it. The problem with this one is
that the llvm tools (lld/llvm-ar/etc) would be missing a feature when
compared to gold/bfd/ld64 using a plugin, which is odd. This was first
implemented to get real software linking with lto and llvm, so there
is evidence that the it is useful to do the extra effort to reduce the
changes needed in a given project to enable LTO.

 Another option is to invert the MC -> Object dependency so that
IRObjectFile can parse assembly. The obvious disadvantage is the extra
dependency for users of Object. Another less obvious one is that we
don't have a handy place to store things like MCAsmInfo and end up
looking for them for every object file.

The attached patch implements the above option. It is mostly code
moving and most of that is because of code that doesn't seem to fit in
lib/MC. Check the thread "Somewhat unrelated code in lib/MC" in
llvmdev for the details.

The long term solution is probably to use a factory to create object
files. That is, instead of doing

createBinary(...)

We would do

Factory.createBinary(...)

With that IRObjectFile could move out of lib/Object. Code using IR
would register a constructor for the IRObjectFile. The factory would
also provide a place to store a MCContext and other info the IR
handling wants.

The question in then if the attached patch (after cleanups) is a
reasonable short term compromise.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch.bz2
Type: application/x-bzip2
Size: 18887 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140629/761b03b4/attachment.bin>