[llvm-dev] Linker Option support for ELF

[Sean Silva via llvm-dev]

On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.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).
>

Do we have agreement about this assumption? I think one main point of
disagreement is how open-ended we want things, and llvm.linker.options
implies, at least at first glance, a very open-ended approach. Can you
describe how open-ended llvm.linker.options is, in fact/in practice? I.e.
what subset of linker options do the COFF/MachO targets actually support?


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

One thing that is on my mind is that the fact that llvm.linker.options is
metadata means it can be dropped. So, playing devil's advocate here, it is
correct for ELF targets to just ignore it (as they currently do AFAIK). if
your intended use case does not actually behave correctly with the
llvm.linker.options dropped, then that suggests that something is fishy.

I guess the fact that llvm.linker.options is currently used for COFF/MachO
suggests that it is not dropped in practice in the situations that matter,
but it does provide some evidence that we may want to move away from
llvm.linker.options. For example, we could let frontends parse legacy
open-ended linker pragmas and emit a new IR format with constrained
semantics.

(also, do you know if the COFF/MachO representation for the linker options
in the .o file can/cannot be dropped? AFAIK, SHT_NOTE can be ignored)

I just find it very fishy to consider linker options as advisory.
Presumably if a user is passing them, then they are required for
correctness.

-- Sean Silva



>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/79e10c5b/attachment.html>