llvm dev - Jan 2018 - Linker Option support for ELF

We should do this. ELF is the odd duck out that lacks this capability.

I agree with Rafael we should have a whitelist of flags that we support,
but I'd rather leave the syntax as more or less just a response file.
That's basically what's implemented for COFF.

Sent from phone

On Wed, Jan 3, 2018, 4:13 PM Rafael Avila de Espindola via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
> The format should also be discussed at least with the gnu linker
> maintainers and ideally on generic-abi at googlegroups.com.
>
> Cheers,
> Rafael
> _______________________________________________
> 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/20180104/2de3c91d/attachment.html>

On Wed, Jan 3, 2018 at 8:30 PM, Reid Kleckner <rnk at google.com> wrote:
> We should do this. ELF is the odd duck out that lacks this capability.
>
Exactly, and the amount of work that swift goes through to accommodate this
is silly.

> I agree with Rafael we should have a whitelist of flags that we support,
> but I'd rather leave the syntax as more or less just a response file.
> That's basically what's implemented for COFF.
>
This is precisely what I have been proposing: we pass through everything as
if it as a response file, and the linker can whitelist the flags.

>
> Sent from phone
>
> On Wed, Jan 3, 2018, 4:13 PM Rafael Avila de Espindola via llvm-dev <
> llvm-dev at lists.llvm.org> 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.
>>
>> The format should also be discussed at least with the gnu linker
>> maintainers and ideally on generic-abi at googlegroups.com.
>>
>> Cheers,
>> Rafael
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

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

Saleem Abdulrasool <compnerd at compnerd.org> writes:
> On Wed, Jan 3, 2018 at 8:30 PM, Reid Kleckner <rnk at google.com>
wrote:
>
>> We should do this. ELF is the odd duck out that lacks this capability.
>>
>
> Exactly, and the amount of work that swift goes through to accommodate this
> is silly.
>
>
>> I agree with Rafael we should have a whitelist of flags that we
support,
>> but I'd rather leave the syntax as more or less just a response
file.
>> That's basically what's implemented for COFF.
>>
>
> This is precisely what I have been proposing: we pass through everything as
> if it as a response file, and the linker can whitelist the flags.
As long as we are strict with the white list and clearly document each
allowed flag, that is fine with me.

Cheers,
Rafael