[llvm-dev] Linker Option support for ELF

[Peter Smith via llvm-dev]

On 8 January 2018 at 09:32, James Henderson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 8 January 2018 at 08:14, Rui Ueyama <ruiu at google.com> wrote:
>>
>> On Mon, Jan 8, 2018 at 3:55 AM, Sean Silva via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>>
>>>
>>> On Jan 7, 2018 5:02 PM, "Cary Coutant via llvm-dev"
>>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>> > I think we all agree that blindly allowing the linker to honor the
>>> > options
>>> > would be scary.  I agree that we should whitelist the options, and am
>>> > of the
>>> > opinion that we should force validation on the linker side (use of any
>>> > option which the linker doesn't support in this form can be fatal).
>>> > Starting small is the best way, with `-l` and `-L` as a starting point.
>>> > I
>>> > want to retain the ability to add additional options which may not be
>>> > available in all linkers.  However, whitelisting obviously requires
>>> > working
>>> > with the linker as would adding such options, so that could be handled
>>> > at
>>> > that time.
>>>
>>> This is actually why I'd prefer a new "language" over just
>>> whitelisting options. With "lib", "file", and "path", as I suggested,
>>> there's no question whether an option like "-no-pie" is supported, and
>>> no temptation to even try.
>>>
>>>
>>> That's a very simple and elegant solution.
>>
>>
>> I really like that approach too. Command line options and "embedded
>> options" are different, so making them actually look different makes sense.
>
>
> +1 from me. This is very similar to what we have in the Playstation linker
> (which uses integers instead of strings to denote the type of directive). As
> Paul mentioned earlier, we support "lib" and "export" directives, both of
> which would fit nicely into this format.
>
>>

I'm wondering how much of the likely extensions are already covered by
linker script commands
(https://sourceware.org/binutils/docs/ld/File-Commands.html#File-Commands).
Would it be worth investigating embedding fragments of linker script
[*] in the same way as the .directive sections that could be
concatenated or overridden by any user provided linker script? This
would have some advantages:
- there is already a specification and implementation of the commands
and experience of their use and limitations.
- it will be easier to resolve conflicts with existing linker script
commands that might conflict.
- if new commands are needed they can be added to linker scripts.

[*] The encoding in the object file need not match, as long as the
permitted set of options can map 1:1 to a linker script command.

My experience with Arm Build Attributes, which are used to reason
about compatibility of relocatable objects and not communication of
options; is that users expect to be able to move binary only objects
between projects, and information embedded in object files that isn't
easily accessible to them that causes a link to fail is extremely
unpopular. I'm definitely of the opinion that we should be cautious
with what we allow to be put in.

Peter