<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 9:54 AM, Dave Bozier <span dir="ltr"><<a href="mailto:seifsta@gmail.com" target="_blank">seifsta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Ok, I see. Does it help that there are LTOModule (lto_module_* in the<br>
> C API) interfaces for checking if a file contains bitcode (regardless<br>
> of whether it is straight-up or native-wrapped)?<br>
<br>
</span>Unfortunately no it won't help. We try to identify inputs on the<br>
command line in the order 1) Object 2) static library 3) Bitcode 4)<br>
Linker script. Our LTO implementation is split into a separate process<br>
that is lazily loaded only in the case that we are trying to identify<br>
an input and don't recognize it as an object or static library and<br>
suspect it is a bitcode file.<br>
<span class=""><br></span></blockquote><div><br></div><div>This sounds a little fragile and inflexible. How is the command line formed?</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I don't know how hard<br>
> in your linker it is to query these when deciding whether to treat the<br>
> object file as bitcode or not, or how hard it is to pass the resulting<br>
> object file along to the libLTO routines for handling (they<br>
> automatically handle the native-wrapped object files so the linker<br>
> shouldn't have to do anything special to read them).<br>
<br>
</span>It will be difficult with our current design and without compromise.<br>
Either we change our Identify routines to process the section headers<br>
(can be costly for COMDAT heavy code or code built with<br>
-ffuntion-sections, --fdata-sections). Or we change our ELF scan<br>
routines to specially identify and handle ELF with llvmbc differently.<br>
<br></blockquote><div><br></div><div>At least for ELF, there is a e_machine field in the Elf header that can potentially be useful here.</div><div><br></div><div> </div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternatively could we mark the native file header in a way that<br>
identifies it as a bitcode wrapper is an option? That way we wouldn't<br>
need to parse the section headers upfront to identify how the input<br>
should be treated. This is possibly something we can look at as a<br>
private change.<br>
<span class=""><br>
> Specifically, in the C API these are the lto_module_is_object_file*<br>
> variants, which will return true for either straight-up or<br>
> native-wrapped bitcode. All of the mechanics of handling bitcode vs<br>
> native object-wrapped bitcode are down in the IRObjectFile handling.<br>
> So the LTOModule:isBitcode*/lto_module_is_object_file* will correctly<br>
> identify native object-wrapped bitcode as bitcode. And the<br>
> LTOModule::createFrom*/lto_module_create* routines correctly parse the<br>
> native object-wrapped bitcode and return an LTOmodule.<br>
<br>
</span>It's great to see these API functions have been considered and added<br>
to libLTO and I'm sure they will help for other tools. Unfortunately<br>
not ours.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>