[llvm-dev] Linker Option support for ELF

[Rui Ueyama via llvm-dev]

Thank you for starting the discussion thread.

In general I'm in favor of the proposal. Defining a generic way to convey
some information from the compiler to the linker is useful, and it looks
like it is just a historical reason that the ELF lacks the feature at the
moment.

This is a scenario in which the feature is useful: when you include math.h,
a compiler (which is driven by some pragma) could added `-lm` to the note
section so that a linker automatically links libm.

I think I'm also in favor of the format, which is essentially runs of
null-terminated strings (*1) that are basically opaque to compilers.

However, you should define as a spec what options are allowed and what
their semantics are. We should not accept arbitrary linker options because
semantics of some linker options cannot be clearly defined when they appear
as embedded options. Just saying "this feature allows you to embed linker
options to object files" is too weak as a specification. You need to
clearly define a list of options that will be supported by linkers with
their clear semantics.

(*1) One of the big annoyances that I noticed when I was implementing the
same feature for COFF is that the COFF's .drctve section that contains
linker options have to be tokenized in the same way as the Windows command
line does. So it needs to interpret double quotes and backslashes correctly
especially when handling space-containing pathnames. This is a design
failure that a COFF file contains just a single string instead of runs of
strings that have already been tokenized.

On Thu, Jan 4, 2018 at 9:02 AM, Saleem Abdulrasool via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hello all,
>
> There was some interest from a number of a few people about adding support
> for embedded linker options to ELF.  This would be an extension that
> requires linker support to actually work, but has significant prior art
> with PE/COFF as well as MachO both having support for this.
>
> The desire here is to actually add support to LLVM to pass along the
> necessary information into the object file.  In order to keep this focused
> on that, this thread is specifically for the *backend*, we are not
> discussing how to get the information to the backend here at all, but
> assuming that the information is present in the same LLVM IR encoding
> (llvm.linker-options module metadata string).
>
> In order to have compatibility with existing linkers, I am suggesting the
> use of an ELF note.  These are implicitly dropped by the linker so we can
> be certain that the options will not end up in the final binary even if the
> extension is not supported.  The payload would be a 4-byte version
> identifier (to allow future enhancements) and a null-terminated string of
> options.
>
> This allows for the backend to be entirely oblivious to the data as the
> other backends and allows for extensions in the future without having to
> teach the backend anything about the new functionality (again, something
> which both of the other file formats support).
>
> As an example of how this can be useful, it would help with Swift support
> on Linux where currently the linker options are pushed into a custom
> section, and a secondary program is used to extract the options from this
> section prior to the linker being invoked.  This adds a lot of complexity
> to the driver as well as additional tools being invoked in the build chain
> slowing down the build.
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180105/63bfb31f/attachment.html>