[llvm-dev] Linker Option support for ELF

[Rui Ueyama via llvm-dev]

On Mon, Jan 8, 2018 at 3:22 AM, Peter Smith <peter.smith at linaro.org> wrote:

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

If we allow users embed linker scripts to object files, all ELF linkers
will have to start supporting the linker script even for linking trivial
programs. I don't think that's a good situation. IMO linker script is too
powerful and too GNU-ish that we want to use it only for some limited
purposes (e.g. embedded programming.)

[*] 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180108/eb823343/attachment.html>