From: Florian Weimer <fw@deneb.enyo.de>
To: Nicholas Piggin via Libc-alpha <libc-alpha@sourceware.org>
Cc: libc-dev@lists.llvm.org, Rich Felker <dalias@libc.org>,
linuxppc-dev@lists.ozlabs.org,
Nicholas Piggin <npiggin@gmail.com>,
musl@lists.openwall.com
Subject: Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Date: Thu, 16 Apr 2020 22:18:18 +0200 [thread overview]
Message-ID: <87wo6fchh1.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <1587004907.ioxh0bxsln.astroid@bobo.none> (Nicholas Piggin via Libc-alpha's message of "Thu, 16 Apr 2020 12:53:31 +1000")
* Nicholas Piggin via Libc-alpha:
> We may or may not be getting a new ABI that will use instructions not
> supported by old processors.
>
> https://sourceware.org/legacy-ml/binutils/2019-05/msg00331.html
>
> Current ABI continues to work of course and be the default for some
> time, but building for new one would give some opportunity to drop
> such support for old procs, at least for glibc.
If I recall correctly, during last year's GNU Tools Cauldron, I think
it was pretty clear that this was only to be used for intra-DSO ABIs,
not cross-DSO optimization. Relocatable object files have an ABI,
too, of course, so that's why there's a ABI documentation needed.
For cross-DSO optimization, the link editor would look at the DSO
being linked in, check if it uses the -mfuture ABI, and apply some
shortcuts. But at that point, if the DSO is swapped back to a version
built without -mfuture, it no longer works with those newly linked
binaries against the -mfuture version. Such a thing is a clear ABI
bump, and based what I remember from Cauldron, that is not the plan
here.
(I don't have any insider knowledge—I just don't want people to read
this think: gosh, yet another POWER ABI bump. But the PCREL stuff
*is* exciting!)
next prev parent reply other threads:[~2020-04-16 20:20 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 21:45 Powerpc Linux 'scv' system call ABI proposal take 2 Nicholas Piggin
2020-04-15 22:55 ` [musl] " Rich Felker
2020-04-16 0:16 ` Nicholas Piggin
2020-04-16 0:48 ` Rich Felker
2020-04-16 2:24 ` Nicholas Piggin
2020-04-16 2:35 ` Rich Felker
2020-04-16 2:53 ` Nicholas Piggin
2020-04-16 3:03 ` Rich Felker
2020-04-16 3:41 ` Nicholas Piggin
2020-04-16 20:18 ` Florian Weimer [this message]
2020-04-16 9:58 ` Szabolcs Nagy
2020-04-20 0:27 ` Nicholas Piggin
2020-04-20 1:29 ` Rich Felker
2020-04-20 2:08 ` Nicholas Piggin
2020-04-20 21:17 ` Szabolcs Nagy
2020-04-21 9:57 ` Florian Weimer
2020-04-16 15:21 ` Jeffrey Walton
2020-04-16 15:40 ` Rich Felker
2020-04-16 4:48 ` Florian Weimer
2020-04-16 15:35 ` Rich Felker
2020-04-16 16:42 ` Florian Weimer
2020-04-16 16:52 ` Rich Felker
2020-04-16 18:12 ` Florian Weimer
2020-04-16 23:02 ` Segher Boessenkool
2020-04-17 0:34 ` Rich Felker
2020-04-17 1:48 ` Segher Boessenkool
2020-04-17 8:34 ` Florian Weimer
2020-04-16 14:16 ` Adhemerval Zanella
2020-04-16 15:37 ` Rich Felker
2020-04-16 17:50 ` Adhemerval Zanella
2020-04-16 17:59 ` Rich Felker
2020-04-16 18:18 ` Adhemerval Zanella
2020-04-16 18:31 ` Rich Felker
2020-04-16 18:44 ` Rich Felker
2020-04-16 18:52 ` Adhemerval Zanella
2020-04-20 0:46 ` Nicholas Piggin
2020-04-20 1:10 ` Nicholas Piggin
2020-04-20 1:34 ` Rich Felker
2020-04-20 2:32 ` Nicholas Piggin
2020-04-20 4:09 ` Rich Felker
2020-04-20 4:31 ` Nicholas Piggin
2020-04-20 17:27 ` Rich Felker
2020-04-22 6:18 ` Nicholas Piggin
2020-04-22 6:29 ` Nicholas Piggin
2020-04-23 2:36 ` Rich Felker
2020-04-23 12:13 ` Adhemerval Zanella
2020-04-23 16:18 ` Rich Felker
2020-04-23 16:35 ` Adhemerval Zanella
2020-04-23 16:43 ` Rich Felker
2020-04-23 17:15 ` Adhemerval Zanella
2020-04-23 17:42 ` Rich Felker
2020-04-25 3:40 ` Nicholas Piggin
2020-04-25 4:52 ` Rich Felker
2020-04-25 3:30 ` Nicholas Piggin
2020-04-21 12:28 ` David Laight
2020-04-21 14:39 ` Rich Felker
2020-04-21 15:00 ` Adhemerval Zanella
2020-04-21 15:31 ` David Laight
2020-04-22 6:54 ` Nicholas Piggin
2020-04-22 7:15 ` [musl] " Florian Weimer
2020-04-22 7:31 ` Nicholas Piggin
2020-04-22 8:11 ` 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=87wo6fchh1.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-dev@lists.llvm.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=musl@lists.openwall.com \
--cc=npiggin@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.