[patch][rfc] Handling inline assembly in IRObjectFile

[Rafael Espíndola]

Rebased patch attached.



On 29 June 2014 01:56, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 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
Type: text/x-patch
Size: 49660 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140702/dbf0c950/attachment.bin>