<div dir="ltr">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.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. =]</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Sat, Jun 28, 2014 at 10:56 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When using plugins with gold or ld64 we are able to handle symbols<br>
being defined and used from inline assembly. This is critical for lld<br>
which needs the information for GC (I think) but is also handy for<br>
gold since it allows it to fetch archive members correctly and avoids<br>
us internalizing globals in one file that are used from assembly in<br>
another.<br>
<br>
There a few options on how to handle this in the llvm tools world, all<br>
with some undesirabilities.<br>
<br>
One options would be simply: don't do it. The problem with this one is<br>
that the llvm tools (lld/llvm-ar/etc) would be missing a feature when<br>
compared to gold/bfd/ld64 using a plugin, which is odd. This was first<br>
implemented to get real software linking with lto and llvm, so there<br>
is evidence that the it is useful to do the extra effort to reduce the<br>
changes needed in a given project to enable LTO.<br>
<br>
 Another option is to invert the MC -> Object dependency so that<br>
IRObjectFile can parse assembly. The obvious disadvantage is the extra<br>
dependency for users of Object. Another less obvious one is that we<br>
don't have a handy place to store things like MCAsmInfo and end up<br>
looking for them for every object file.<br>
<br>
The attached patch implements the above option. It is mostly code<br>
moving and most of that is because of code that doesn't seem to fit in<br>
lib/MC. Check the thread "Somewhat unrelated code in lib/MC" in<br>
llvmdev for the details.<br>
<br>
The long term solution is probably to use a factory to create object<br>
files. That is, instead of doing<br>
<br>
createBinary(...)<br>
<br>
We would do<br>
<br>
Factory.createBinary(...)<br>
<br>
With that IRObjectFile could move out of lib/Object. Code using IR<br>
would register a constructor for the IRObjectFile. The factory would<br>
also provide a place to store a MCContext and other info the IR<br>
handling wants.<br>
<br>
The question in then if the attached patch (after cleanups) is a<br>
reasonable short term compromise.<br>
<br>
Cheers,<br>
Rafael<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>