From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>,
nathanl@linux.ibm.com, arnd@arndb.de,
linux-kernel@vger.kernel.org,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
Paul Mackerras <paulus@samba.org>,
luto@kernel.org, linux-arch@vger.kernel.org, tglx@linutronix.de,
vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
Date: Thu, 6 Aug 2020 13:33:16 -0500 [thread overview]
Message-ID: <20200806183316.GV6753@gate.crashing.org> (raw)
In-Reply-To: <87r1sky1hm.fsf@mpe.ellerman.id.au>
Hi!
On Thu, Aug 06, 2020 at 12:03:33PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote:
> >> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> >> > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
> >> > frame whenever it has anything to same.
^^^
> >> > fbb60: 94 21 ff e0 stwu r1,-32(r1)
> >
> > This is the *only* place where you can use a negative offset from r1:
> > in the stwu to extend the stack (set up a new stack frame, or make the
> > current one bigger).
>
> (You're talking about 32-bit code here right?)
The "SYSV" ELF binding, yeah, which is used for 32-bit on Linux (give or
take, ho hum).
The ABIs that have a red zone are much nicer here (but less simple) :-)
> >> At the same time it's much safer for us to just save/restore r2, and
> >> probably in the noise performance wise.
> >
> > If you want a function to be able to work with ABI-compliant code safely
> > (in all cases), you'll have to make it itself ABI-compliant as well,
> > yes :-)
>
> True. Except this is the VDSO which has previously been a bit wild west
> as far as ABI goes :)
It could get away with many things because it was guaranteed to be a
leaf function. Some of those things even violate the ABIs, but you can
get away with it easily, much reduced scope. Now if this is generated
code, violating the rules will catch up with you sooner rather than
later ;-)
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
nathanl@linux.ibm.com, linux-arch@vger.kernel.org, arnd@arndb.de,
linux-kernel@vger.kernel.org,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
luto@kernel.org, tglx@linutronix.de, vincenzo.frascino@arm.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
Date: Thu, 6 Aug 2020 13:33:16 -0500 [thread overview]
Message-ID: <20200806183316.GV6753@gate.crashing.org> (raw)
Message-ID: <20200806183316.aIgtFstDr6KepSkoSpheH66sXzFVsndfmU7fTcUp32M@z> (raw)
In-Reply-To: <87r1sky1hm.fsf@mpe.ellerman.id.au>
Hi!
On Thu, Aug 06, 2020 at 12:03:33PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote:
> >> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> >> > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
> >> > frame whenever it has anything to same.
^^^
> >> > fbb60: 94 21 ff e0 stwu r1,-32(r1)
> >
> > This is the *only* place where you can use a negative offset from r1:
> > in the stwu to extend the stack (set up a new stack frame, or make the
> > current one bigger).
>
> (You're talking about 32-bit code here right?)
The "SYSV" ELF binding, yeah, which is used for 32-bit on Linux (give or
take, ho hum).
The ABIs that have a red zone are much nicer here (but less simple) :-)
> >> At the same time it's much safer for us to just save/restore r2, and
> >> probably in the noise performance wise.
> >
> > If you want a function to be able to work with ABI-compliant code safely
> > (in all cases), you'll have to make it itself ABI-compliant as well,
> > yes :-)
>
> True. Except this is the VDSO which has previously been a bit wild west
> as far as ABI goes :)
It could get away with many things because it was guaranteed to be a
leaf function. Some of those things even violate the ABIs, but you can
get away with it easily, much reduced scope. Now if this is generated
code, violating the rules will catch up with you sooner rather than
later ;-)
Segher
next prev parent reply other threads:[~2020-08-06 18:33 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 13:16 [PATCH v8 0/8] powerpc: switch VDSO to C implementation Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 1/8] powerpc/vdso64: Switch from __get_datapage() to get_datapage inline macro Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 2/8] powerpc/vdso: Remove __kernel_datapage_offset and simplify __get_datapage() Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-07-16 2:59 ` Michael Ellerman
2020-08-04 11:17 ` Christophe Leroy
2020-08-04 11:17 ` Christophe Leroy
2020-08-25 14:15 ` Christophe Leroy
2020-08-26 13:58 ` Michael Ellerman
2020-08-27 20:34 ` Dmitry Safonov
2020-08-28 2:14 ` Michael Ellerman
2020-09-21 11:26 ` Will Deacon
2020-09-27 7:43 ` Christophe Leroy
2020-09-28 15:08 ` Dmitry Safonov
2020-10-23 11:22 ` Christophe Leroy
2020-10-23 11:25 ` Will Deacon
2020-10-23 11:57 ` Christophe Leroy
2020-10-23 13:29 ` Dmitry Safonov
2020-04-28 13:16 ` [PATCH v8 3/8] powerpc/vdso: Remove unused \tmp param in __get_datapage() Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 4/8] powerpc/processor: Move cpu_relax() into asm/vdso/processor.h Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-07-15 1:04 ` Michael Ellerman
2020-07-15 1:04 ` Michael Ellerman
2020-07-15 18:47 ` Christophe Leroy
2020-07-16 23:18 ` Tulio Magno Quites Machado Filho
2020-08-04 11:14 ` Christophe Leroy
2020-08-04 11:14 ` Christophe Leroy
2020-08-05 6:24 ` Michael Ellerman
2020-08-05 13:35 ` Segher Boessenkool
2020-08-05 13:35 ` Segher Boessenkool
2020-08-06 2:03 ` Michael Ellerman
2020-08-06 18:33 ` Segher Boessenkool [this message]
2020-08-06 18:33 ` Segher Boessenkool
2020-08-07 2:44 ` Michael Ellerman
2020-04-28 13:16 ` [PATCH v8 6/8] powerpc/vdso: Switch " Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 7/8] lib/vdso: force inlining of __cvdso_clock_gettime_common() Christophe Leroy
2020-04-28 13:16 ` Christophe Leroy
2020-04-28 13:16 ` [PATCH v8 8/8] powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32 Christophe Leroy
2020-04-28 16:05 ` Arnd Bergmann
2020-05-09 15:54 ` Christophe Leroy
2020-05-09 18:48 ` Christophe Leroy
2020-05-29 18:56 ` [PATCH v8 0/8] powerpc: switch VDSO to C implementation Christophe Leroy
2020-06-03 10:04 ` Michael Ellerman
2020-07-16 12:55 ` Michael Ellerman
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=20200806183316.GV6753@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=arnd@arndb.de \
--cc=christophe.leroy@c-s.fr \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nathanl@linux.ibm.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=tuliom@linux.ibm.com \
--cc=vincenzo.frascino@arm.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 NNTP newsgroup(s).