[LLVMdev] RFC: auto-linking IR proposal

[Daniel Dunbar]

Hi Michael,

Thanks for the feedback.

On Tue, Jan 15, 2013 at 3:18 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:

> On Tue, Jan 15, 2013 at 1:17 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> > Hi all,
> >
> > We plan to add some auto-linking support for Mach-O, and need a scheme
> for
> > encoding this information in the LLVM IR. We would like the same scheme
> to
> > be able to support Microsoft's #pragma comment(lib,...) and #pragma
> > comment(library, ...) features eventually.
> >
> > The current proposal is as follows:
> >
> > --
> >
> > #1. Extend module-level metadata flags (llvm.module.flags) to support two
> > new behaviors:
> >
> > llvm::Module::Append - The value must be a list. Module flags with
> > equivalent unique IDs and this behavior will be appended in the order
> that
> > they are linked.
> >
> > llvm::Module::AppendUnique - The value must be a list. As with
> > llvm::Module::Append, module flags with equivalent unique IDs are
> appended
> > in the order that they are linked. However, identical MDNodes will only
> > appear once in the list (at the earliest seen position).
> >
> > #2. Define a new "known" module level flag metadata "Linker Options"
> which
> > is a list of lists of metadata strings corresponding to linker options.
> This
> > metadata flag will use the llvm::Module::AppendUnique option.
> >
> > The options are expected to be linker specific (thus target specific), we
> > make no attempt to encode the intent of the options at the IR level. The
> > frontend is responsible for selecting appropriate options based on the
> > target.
> >
> > The module level linker will only unique option lists, any diagnosis of
> > otherwise redundant or conflicting options is expected to be handled by
> the
> > linker.
> >
> > Example metadata for a module which is expected to link against libz and
> the
> > Cocoa framework::
> >
> >   !0 = metadata !{ i32 6, "Linker Options",
> >      metadata !{
> >         !metadata { metadata !"-lz" },
> >         !metadata { metadata !"-framework", metadata !"Cocoa" } } }
> >   !llvm.module.flags = !{ !0 }
> >
> > --
> >
> > We have debated whether or not there is value in adopting a more strict
> > schema for the metadata (i.e., declare intent more explicitly by encoding
> > things like static library vs dynamic library vs framework library
> instead
> > of using target-specific linker options). However, as we have no
> expectation
> > that the compiler will want to inspect this data, it seems like this adds
> > complexity (and reduces flexibility) for no benefit. It does, however,
> have
> > the downside that the frontend needs to participate (and have target
> linker
> > knowledge) in order to use the appropriate options.
> >
> > Other points of discussion:
> >
> > #1. On Mach-O, the linker will expect and enforce that each list of
> options
> > corresponds to a single library. This will not be enforced (nor is it
> > enforceable) at the IR level, and other targets wouldn't have this
> > restriction (Visual Studio supports inclusion of some arbitrary flags).
> >
> > #2. On Microsoft, #pragma comment(linker, ...) will map naturally to this
> > format. How #pragma comment(lib, ...) gets handled will probably depend
> on
> > the details of how this is encoded in the COFF object files, which I am
> not
> > yet familiar with.
>
> On COFF #pragma comment(lib, ...) just gets turned into a linker flag
> in the .drectve section.
>

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?

> #3. We make no attempt to encode ordering information amongst the options,
> > which limits the utility for linking against static libraries. The
> current
> > expectation is that this feature be used for system libraries where the
> > order of the options is not important. A schema that would allow encoding
> > dependencies amongst libraries to be auto-linked would be substantially
> more
> > complicated and is outside the scope of this proposal.
>
> What do you mean by amongst the options? #pragma comment(lib, ...)
> requires that the options are added in the order they occur in the
> source file. This should be trivial to implement in the metadata.
>

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).


>
> >
> > Please let me know if you have an opinion on this works, particularly if
> you
> > want to chime in on how this might interact with ELF or COFF.
> >
> >  - Daniel
>
> I don't know of any ELF implementation that currently supports this in
> general, but adding it should't be too hard.
>

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.

 - Daniel


> Go does automatic linking, but it now has its own object file format
> that handles it. gccgo for ELF seems to produce .go_export sections
> and <package>..import symbols which are both specific to Go.
>
> - Michael Spencer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130116/8cddf658/attachment.html>