[llvm-dev] Linker Option support for ELF

[Saleem Abdulrasool via llvm-dev]

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>