[llvm-dev] Linker Option support for ELF

Peter Smith via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 8 03:22:26 PST 2018

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


More information about the llvm-dev mailing list