llvm dev - Jan 2018 - Linker Option support for ELF

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>

Saleem Abdulrasool <compnerd at compnerd.org> writes:
> So you are suggesting that the backend take the opaque blob, peer through
> it, map it to something else and then encode that?
The llvm backend? No, it should probably be done by whatever produced
the IR. If viewing this a part of the file format, having the FE create
a metadata asking for (add_lib_enum_value, "foo.a") is not too
different
than than asking for a particular visibility or dll import.
> 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.
Is some sense that is the idea: forcing each feature to be documented
and discussed. What feature other than "add that lib" do you have in
mind?

Cheers,
Rafael

On Wed, Jan 3, 2018 at 5:04 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Saleem Abdulrasool <compnerd at compnerd.org> writes:
>
> > So you are suggesting that the backend take the opaque blob, peer
through
> > it, map it to something else and then encode that?
>
> The llvm backend? No, it should probably be done by whatever produced
> the IR. If viewing this a part of the file format, having the FE create
> a metadata asking for (add_lib_enum_value, "foo.a") is not too
different
> than than asking for a particular visibility or dll import.
>
Okay, so, that is a different conversation..  Im discussing purely the
encoding from LLVM IR -> object file.  The frontend changes would still
need to be made, and those can be discussed at that point.  Im suggesting
that we treat the current behavior similar to the PE/COFF and MachO
mechanism: it is effectively a response file.

>
> > 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.
>
> Is some sense that is the idea: forcing each feature to be documented
> and discussed. What feature other than "add that lib" do you have
in mind?
>
What about trying to do something like the "-framework" option
(thinking
along the various things that swift has to deal with, which don't exist
yet) or the embedded AST modules (for swift debugging) or additional search
paths.

> 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/ea713e8e/attachment-0001.html>