[llvm-dev] Linker Option support for ELF

[Rafael Avila de Espindola via llvm-dev]

Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> writes:

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

So far LGTM.

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

That is the part I have issues with.

A linker has a lot of command line options, we should not make them part
of the object format. What happens if a file has a -strip-all,
--gc-sections or -pie?

I think the supported features should be explicitly documented and be
encoded a option-number,argument pair.

The format should also be discussed at least with the gnu linker
maintainers and ideally on generic-abi at googlegroups.com.

Cheers,
Rafael