mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Nicholas Piggin <npiggin@gmail.com>,
	libc-alpha@sourceware.org, musl@lists.openwall.com,
	linuxppc-dev@lists.ozlabs.org, libc-dev@lists.llvm.org
Subject: Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Date: Thu, 16 Apr 2020 12:52:57 -0400	[thread overview]
Message-ID: <20200416165257.GY11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <87sgh3e613.fsf@mid.deneb.enyo.de>

On Thu, Apr 16, 2020 at 06:42:32PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote:
> >> * Rich Felker:
> >> 
> >> > My preference would be that it work just like the i386 AT_SYSINFO
> >> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> >> > provides a stub in the vdso that performs either scv or the old
> >> > mechanism with the same calling convention.
> >> 
> >> The i386 mechanism has received some criticism because it provides an
> >> effective means to redirect execution flow to anyone who can write to
> >> the TCB.  I am not sure if it makes sense to copy it.
> >
> > Indeed that's a good point. Do you have ideas for making it equally
> > efficient without use of a function pointer in the TCB?
> 
> We could add a shared non-writable mapping at a 64K offset from the
> thread pointer and store the function pointer or the code there.  Then
> it would be safe.
> 
> However, since this is apparently tied to POWER9 and we already have a
> POWER9 multilib, and assuming that we are going to backport the kernel
> change, I would tweak the selection criterion for that multilib to
> include the new HWCAP2 flag.  If a user runs this glibc on a kernel
> which does not have support, they will get set baseline (POWER8)
> multilib, which still works.  This way, outside the dynamic loader, no
> run-time dispatch is needed at all.  I guess this is not at all the
> answer you were looking for. 8-)

How does this work with -static? :-)

> If a single binary is needed, I would perhaps follow what Arm did for
> -moutline-atomics: lay out the code so that its easy to execute for
> the non-POWER9 case, assuming that POWER9 machines will be better at
> predicting things than their predecessors.
> 
> Or you could also put the function pointer into a RELRO segment.  Then
> there's overlap with the __libc_single_threaded discussion, where
> people objected to this kind of optimization (although I did not
> propose to change the TCB ABI, that would be required for
> __libc_single_threaded because it's an external interface).

Of course you can use a normal global, but now every call point needs
to setup a TOC pointer (= two entry points and more icache lines for
otherwise trivial functions).

I think my choice would be just making the inline syscall be a single
call insn to an asm source file that out-of-lines the loading of TOC
pointer and call through it or branch based on hwcap so that it's not
repeated all over the place.

Alternatively, it would perhaps work to just put hwcap in the TCB and
branch on it rather than making an indirect call to a function pointer
in the TCB, so that the worst you could do by clobbering it is execute
the wrong syscall insn and thereby get SIGILL.

Rich

  reply	other threads:[~2020-04-16 16:53 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 21:45 Nicholas Piggin
2020-04-15 22:55 ` 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
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 [this message]
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                       ` [musl] " Nicholas Piggin
2020-04-22  7:15                         ` 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=20200416165257.GY11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=fw@deneb.enyo.de \
    --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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).