public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Fangrui Song <maskray@google.com>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	 Fangrui Song via Libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] install: Delete scripts/output-format.sed and support lld
Date: Sun, 3 May 2020 14:11:13 -0700	[thread overview]
Message-ID: <CAMe9rOr-k2o1tCw=28D4dXnUvY7j63XHkrEc=+CdPQfeusf7YQ@mail.gmail.com> (raw)
In-Reply-To: <20200503205340.2lvhsr3t3qvuieoi@google.com>

On Sun, May 3, 2020 at 1:54 PM Fangrui Song via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On 2020-05-03, Florian Weimer wrote:
> >* Fangrui Song via Libc-alpha:
> >
> >> GNU ld and gold can skip a script with incompatible OUTPUT_FORMAT and
> >> find the next script in the search path. So libc.so linked with lld
> >> cannot be skipped automatically. However, this is considered a minor
> >> functionality loss by lld maintainers.
> >
> >That completely depends on how typical installations set up their
> >linker search paths.  Figuring that out is likely more work than
> >providing the correct OUTPUT_FORMAT information in the linker script,
> >so I'm not sure if the patch goes in the right direction.
>
> For typical installations, OUTPUT_FORMAT is not useful.
> Even in multilib installations, OUTPUT_FORMAT is not useful unless, for
> example, /usr/lib is in both -m32 and -m64's library search paths (this
> is likely a misconfiguration).
>
> `OUTPUT_FORMAT(elf64-x86-64)` can provide some protection for GNU ld and
> gold.
>
> >But as I said, it's probably better to find an alternative way to
> >generate the right OUTPUT_FORMAT directive for the linker script.
>
> We (LLD developers) consider OUTPUT_FORMAT with GNU ld/gold semantic has
> very little value. See https://bugs.llvm.org/show_bug.cgi?id=37432 and
> https://bugs.llvm.org/show_bug.cgi?id=43740
>
> >In any case, the choice of linker for building glibc should result in
> >as little semantic difference in the produced artifacts, to avoid
> >inflating the compatibility matrix.  If OUTPUT_FORMAT is indeed
> >unnecessary (based on the evaluation I mentioned), it should be
> >removed unconditionally.
>
> If there is concern about the aforementioned value, then we probably
> should not drop OUTPUT_FORMAT for now for GNU ld/gold. If people think
> we can remove OUTPUT_FORMAT as well, I will be happy to create a
> follow-up patch.

Historical usage of OUTPUT_FORMAT was used to link object files of
non-Linux/x86 formats and generate Linux/x86 output.  It was very useful
during the days when many binary only libraries weren't available for
Linux/x86.  It is still somewhat useful to link ELF object files for a different
OS.  In both cases, the format of the first input file isn't the format of the
output.  That is where OUTPUT_FORMAT comes in.


-- 
H.J.

  reply	other threads:[~2020-05-03 21:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11 23:23 Fangrui Song
2020-04-30  5:39 ` Fangrui Song
2020-05-03 20:30 ` Florian Weimer
2020-05-03 20:53   ` Fangrui Song
2020-05-03 21:11     ` H.J. Lu [this message]
2020-08-31 18:04       ` Fāng-ruì Sòng
2020-08-31 18:07         ` Florian Weimer
2020-08-31 18:52           ` Fāng-ruì Sòng
2020-08-31 23:10             ` H.J. Lu
2020-08-31 23:34               ` Fāng-ruì Sòng
2020-09-01 10:38             ` Florian Weimer
2020-09-01 16:12               ` Fāng-ruì Sòng
2020-09-21 11:31                 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOr-k2o1tCw=28D4dXnUvY7j63XHkrEc=+CdPQfeusf7YQ@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=fw@deneb.enyo.de \
    --cc=libc-alpha@sourceware.org \
    --cc=maskray@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).