<div dir="ltr">Hi Michael,<div><br></div><div style>Thanks for the feedback.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 3:18 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jan 15, 2013 at 1:17 PM, Daniel Dunbar <<a href="mailto:daniel@zuster.org">daniel@zuster.org</a>> wrote:<br>

> Hi all,<br>
><br>
> We plan to add some auto-linking support for Mach-O, and need a scheme for<br>
> encoding this information in the LLVM IR. We would like the same scheme to<br>
> be able to support Microsoft's #pragma comment(lib,...) and #pragma<br>
> comment(library, ...) features eventually.<br>
><br>
> The current proposal is as follows:<br>
><br>
> --<br>
><br>
> #1. Extend module-level metadata flags (llvm.module.flags) to support two<br>
> new behaviors:<br>
><br>
> llvm::Module::Append - The value must be a list. Module flags with<br>
> equivalent unique IDs and this behavior will be appended in the order that<br>
> they are linked.<br>
><br>
> llvm::Module::AppendUnique - The value must be a list. As with<br>
> llvm::Module::Append, module flags with equivalent unique IDs are appended<br>
> in the order that they are linked. However, identical MDNodes will only<br>
> appear once in the list (at the earliest seen position).<br>
><br>
> #2. Define a new "known" module level flag metadata "Linker Options" which<br>
> is a list of lists of metadata strings corresponding to linker options. This<br>
> metadata flag will use the llvm::Module::AppendUnique option.<br>
><br>
> The options are expected to be linker specific (thus target specific), we<br>
> make no attempt to encode the intent of the options at the IR level. The<br>
> frontend is responsible for selecting appropriate options based on the<br>
> target.<br>
><br>
> The module level linker will only unique option lists, any diagnosis of<br>
> otherwise redundant or conflicting options is expected to be handled by the<br>
> linker.<br>
><br>
> Example metadata for a module which is expected to link against libz and the<br>
> Cocoa framework::<br>
><br>
>   !0 = metadata !{ i32 6, "Linker Options",<br>
>      metadata !{<br>
>         !metadata { metadata !"-lz" },<br>
>         !metadata { metadata !"-framework", metadata !"Cocoa" } } }<br>
>   !llvm.module.flags = !{ !0 }<br>
><br>
> --<br>
><br>
> We have debated whether or not there is value in adopting a more strict<br>
> schema for the metadata (i.e., declare intent more explicitly by encoding<br>
> things like static library vs dynamic library vs framework library instead<br>
> of using target-specific linker options). However, as we have no expectation<br>
> that the compiler will want to inspect this data, it seems like this adds<br>
> complexity (and reduces flexibility) for no benefit. It does, however, have<br>
> the downside that the frontend needs to participate (and have target linker<br>
> knowledge) in order to use the appropriate options.<br>
><br>
> Other points of discussion:<br>
><br>
> #1. On Mach-O, the linker will expect and enforce that each list of options<br>
> corresponds to a single library. This will not be enforced (nor is it<br>
> enforceable) at the IR level, and other targets wouldn't have this<br>
> restriction (Visual Studio supports inclusion of some arbitrary flags).<br>
><br>
> #2. On Microsoft, #pragma comment(linker, ...) will map naturally to this<br>
> format. How #pragma comment(lib, ...) gets handled will probably depend on<br>
> the details of how this is encoded in the COFF object files, which I am not<br>
> yet familiar with.<br>
<br>
</div></div>On COFF #pragma comment(lib, ...) just gets turned into a linker flag<br>
in the .drectve section.<br></blockquote><div><br></div><div style>Ok. Can you elaborate a bit more on what that looks like? Does it end up in the same format as #pragma comment(linker, ...), or does the COFF writer need to be able to discriminate between them?</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> #3. We make no attempt to encode ordering information amongst the options,<br>
> which limits the utility for linking against static libraries. The current<br>
> expectation is that this feature be used for system libraries where the<br>
> order of the options is not important. A schema that would allow encoding<br>
> dependencies amongst libraries to be auto-linked would be substantially more<br>
> complicated and is outside the scope of this proposal.<br>
<br>
</div>What do you mean by amongst the options? #pragma comment(lib, ...)<br>
requires that the options are added in the order they occur in the<br>
source file. This should be trivial to implement in the metadata.<br></blockquote><div><br></div><div style>Ah, I glossed over this. Naturally we will retain things in the order they are present in the IR, what I meant was there is no attempt to define a more complex dependency scheme (i.e. encode dependencies among individual options so that linking essentially would topologically sort them).</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> Please let me know if you have an opinion on this works, particularly if you<br>
> want to chime in on how this might interact with ELF or COFF.<br>
><br>
>  - Daniel<br>
<br>
</div>I don't know of any ELF implementation that currently supports this in<br>
general, but adding it should't be too hard.<br></blockquote><div><br></div><div style>Right. Most of the work is in the linker side where it may involve additional policy decisions. On Windows, for example, the linker handles options that come from .obj files differently than other ones, its not just a matter of adding them in to the user specified ones. On Mach-O, the linker will handle such options slightly differently than command line options and only use them as necessary (to resolve missing symbols), but not treat them as required to be linked.</div>
<div style><br></div><div style> - Daniel</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Go does automatic linking, but it now has its own object file format<br>
that handles it. gccgo for ELF seems to produce .go_export sections<br>
and <package>..import symbols which are both specific to Go.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Michael Spencer<br>
</font></span></blockquote></div><br></div></div>