[patch][rfc] Handling inline assembly in IRObjectFile

[Chandler Carruth]

I know that I kind of pushed in the direction of avoiding reversing the
dependency edge between lib/Object and lib/MC, but I think I was just wrong
about that.

Fundamentally, lib/Object is an abstraction across both ELF, MachO, COFF,
*and IR*. As a consequence it has a dependency on lib/IR and its APIs only
make sense based on including that abstraction. Another consequence of this
is that lib/Object needs to depend on lib/MC for inline assembly. That
seems natural and good. The fact that there was an edge the other direction
seems like a bug.

The concern of whether there are clients of lib/Object that don't need all
this is a fine concern, but those clients are *already using the wrong
abstraction*, because they also don't care about IR, and would probably
rather not have the lib/IR dependency. Perhaps we should build a more
minimal library for them, but that can be a separate refactoring.

So, short version, IMO it really makes sense to have parallel and
intrinsically tied dependency edges from lib/Object to both lib/IR and
lib/MC. Make it so. =]


On Sat, Jun 28, 2014 at 10:56 PM, 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140702/62091deb/attachment.html>