[llvm-dev] [lld] Flavour option purpose

Rui Ueyama via llvm-dev
Tue, 14 Nov 2017 02:07:00 -0000

On Mon, Nov 13, 2017 at 9:31 PM, N <scandium at me.com> wrote:

> > For example, MSVC link.exe doesn't have --start-group and
--end-group
> options because their symbol resolution semantics are different than Unix.
>
> Yes, but this is specific for a linker, not for a target. For example, GNU
> ld supports this option for all binary formats. A linker with universal CLI
> would then
> support this flag for all targets as well (or drop the support for all
> targets if recursive dependency resolution can be implemented without that
> flag).
>
> > link.exe on the other hand doesn't have --init or --fini options
because
> that's ELF-only concept.
>
> Yes, so a universal CLI would hide this flag when linking non-ELF
> binaries, as well as any other option not supported by the target currently
> linking for.
> (This is not the same as using a separate flavour for that target.)
>
> > Linker scripts exist only in GNU.
>
>
> My reasoning is the same as for `start-group'. In fact, lld does not
> achieve feature parity with GNU ld configured for mach-o here:
> the latter can use scripts when linking a mach-o binary, but lld cannot
> use scripts at all unless GNU flavor is used, and then mach-o is
> unsupported.
>
> > Also, I think if we try to create a unified interface, I guess it
would
> end up with this situation -- https://xkcd.com/927/. We have three
> standards -- GNU, Darwin and MSVC. I don't know if we want another one.
>
> This depends on whether the flavoured CLIs are removed upon merge. (Of
> course, it is probably impractical to remove them all at once.)
>

You can't really remove any native linker-compatible command line interface
unless you get agreement from all parties including Microsoft and Apple to
switch to the GNU command line as the universal interface in the future
versions of their toolchains. Our linker is designed to be a drop-in
replacement, so in that sense, we are just a follower. If you are really
aiming for a universal command line interface, I think you need to convince
not us but other first-party toolchain developers.

In my opinion, GNU ld has CLI closest to my description, so it is a
good
> basis for a universal interface. In fact, GNU flavour can be universal if
> support
> for more targets is added there, but then the other flavours will likely
> be redundant. One difference would be that a universal CLI need not
> maintain compatibility
> with GNU ld CLI.
>
> > On 1 Nov 2017, at 20:36, Rui Ueyama <ruiu at google.com> wrote:
> >
> > Most command line options in GNU, macOS and MSVC are not just
different
> in terms of notion but different in terms of semantics. For example, MSVC
> link.exe doesn't have --start-group and --end-group options because
their
> symbol resolution semantics are different than Unix. link.exe on the other
> hand doesn't have --init or --fini options because that's ELF-only
concept.
> Linker scripts exist only in GNU. You cannot hide these differences even if
> you create a unified driver, which makes a unified driver less attractive
> to me.
> >
> > Also, I think if we try to create a unified interface, I guess it
would
> end up with this situation -- https://xkcd.com/927/. We have three
> standards -- GNU, Darwin and MSVC. I don't know if we want another one.
> >
> > On Wed, Nov 1, 2017 at 12:16 PM, N via llvm-dev <llvm-dev at
lists.llvm.org>
> wrote:
> > I am aware of these flags, but this is not my point. I am talking
about
> Darwin and Link lld drivers
> > not being on par with the GNU driver. While using clang for linking
> helps, as it provides some flags
> > to the linker, as soon as you want to do something clang does not
> automatically do, you still have
> > the issue of different flags for different drivers/targets.
> >
> > > On 1 Nov 2017, at 20:08, Jonathan Roelofs <jonathan at
codesourcery.com>
> wrote:
> > >
> > >
> > >
> > > On 11/1/17 10:29 AM, N via llvm-dev wrote:
> > >> Thank you for your answers.
> > >> Indeed, Clang is universal, but only until one needs to pass
some
> commands to the linker which are not
> > >> automatically passed by the driver. Then we are back to the
same
> problem.
> > >
> > > Clang and GCC both support the `-Wl,` and `-Xlinker` flags...
> > >
> > >
> > > Jon
> > >
> > >> In my opinion, it would be great if lld had a unified,
GNU-like
> interface. Of course, if nobody else is interested,
> > >> it's probably not even worth it drafting an RFC. :(
> > >>> On 27 Oct 2017, at 01:09, James Y Knight <jyknight at
google.com>
> wrote:
> > >>>
> > >>> I mean, there is such a universal driver -- it's
called "clang".
> > >>>
> > >>>
> > >>> On Oct 26, 2017 5:31 PM, "Rui Ueyama via
llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
> > >>> Martell recently added "ld64.lld" as a name for
the Darwin driver.
> > >>>
> > >>> As to why there's no driver that provides a unified
command line
> arguments, I can't speak for other people. But no one seems to have
been
> interested in it enough to actually invent and implement a set of unified
> command line arguments.
> > >>>
> > >>> On Thu, Oct 26, 2017 at 2:20 PM, N <scandium at
me.com> wrote:
> > >>>> I think using ld.lld or lld-link is preferred way
over "lld -flavor
> gnu" or "lld -flavor link".
> > >>>
> > >>> -flavor seems to be still actively used in Clang… By the
the way,
> there seems to be no special
> > >>> command name for Darwin targets, so ld.lld (incorrectly)
invokes the
> ELF linker there
> > >>> (see https://bugs.llvm.org/show_bug.cgi?id=34792#c1)
> > >>>
> > >>> Regardless, I would be interested in hearing the answer
to the rest
> of the questions.
> > >>>
> > >>>> On 26 Oct 2017, at 23:10, Rui Ueyama <ruiu at
google.com> wrote:
> > >>>>
> > >>>> The -flavor option exists mostly for historical
reasons. I think
> using ld.lld or lld-link is preferred way over "lld -flavor gnu"
or "lld
> -flavor link".
> > >>>>
> > >>>> On Thu, Oct 26, 2017 at 2:06 PM, N via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > >>>> Hi all,
> > >>>>
> > >>>> According to lld/docs/Driver.rst, Flavor command line
option
> determines the style of lld command-line interface when invoked.
> > >>>>
> > >>>> However, it looks like this option also determines
the set of
> supported targets we are linking for. For example, lld -flavor gnu
> > >>>> cannot link mach-o binaries, and could not link PE
binaries either
> (well, not until rL312926).
> > >>>>
> > >>>> Is this really intended by the design of lld? It
looks the flavours
> are merely legacy compatibility shims, but then why is there no
> > >>>> universal lld driver that is able to link binary for
any platform
> using a unified CLI?
> > >>>> _______________________________________________
> > >>>> LLVM Developers mailing list
> > >>>> llvm-dev at lists.llvm.org
> > >>>>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> LLVM Developers mailing list
> > >>> llvm-dev at lists.llvm.org
> > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >>>
> > >>>
> > >> _______________________________________________
> > >> LLVM Developers mailing list
> > >> llvm-dev at lists.llvm.org
> > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > >
> > > --
> > > Jon Roelofs
> > > jonathan at codesourcery.com
> > > CodeSourcery / Mentor Embedded / Siemens
> >
> > _______________________________________________
> > 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/20171114/093fedec/attachment-0001.html>