[llvm-dev] [lld] Flavour option purpose

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Wed Nov 15 17:50:32 PST 2017


On Thu, Nov 16, 2017 at 10:06 AM, Rui Ueyama <ruiu at google.com> wrote:

> On Wed, Nov 15, 2017 at 10:45 PM, N <scandium at me.com> wrote:
>
>> > 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.
>>
>> I completely agree; that's why I said this is not feasible for the time
>> being.
>>
>> I am still wondering about a few things:
>>
>> Is it desired to address the functional difference of the flavours at all?
>>
>> Is it a bug if a flavour has a feature that its original counterpart does
>> not have? For example, would it be
>> acceptable to add scripting support to the Darwin flavour, given that
>> Apple ld64 does not support scripts?
>
>
> No and no. It is not desired and it is not a bug.
>

Sorry, the last "no" is to your last sentence. We generally want to
implement all features to make lld drop-in replacements to the existing
linkers, but any additional features beyond that should be carefully
examined and discussed per-feature basis before being accepted.

> On 14 Nov 2017, at 03:07, Rui Ueyama <ruiu at google.com> wrote:
>> >
>> > 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/20171116/443800b4/attachment.html>


More information about the llvm-dev mailing list