[llvm-dev] Linker Option support for ELF

[Saleem Abdulrasool via llvm-dev]

On Wed, Jan 3, 2018 at 4:13 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

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

So you are suggesting that the backend take the opaque blob, peer through
it, map it to something else and then encode that?  This means that every
single new flag (also consider vendor extensions and non-GNU linkers) would
need their own mapping and would need additional support for every single
variant of an option.  This makes adding support for a flag extremely
expensive IMO.  Filtering options or only supporting a subset of them in a
particular linker is still viable in the approach I have proposed.
Emitting a warning on an unsupported flag and dropping it would be a way to
handle this without adding the complexity in the backend and frontend and
so tightly coupling all the  various pieces of the toolchain.


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

Sure, sending that along to them is perfectly reasonable.

Cheers,
> Rafael


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/d4916ee9/attachment.html>