[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d409421-6396-8eba-8250-b6c9ff8232d9@csgroup.eu>
Date: Wed, 5 Aug 2020 18:51:44 +0200
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>, nathanl@...ux.ibm.com,
anton@...abs.org, linux-arch@...r.kernel.org, arnd@...db.de,
linux-kernel@...r.kernel.org, luto@...nel.org, tglx@...utronix.de,
vincenzo.frascino@....com, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v10 2/5] powerpc/vdso: Prepare for switching VDSO to
generic C implementation.
Hi Again,
Le 05/08/2020 à 16:03, Segher Boessenkool a écrit :
> Hi!
>
> On Wed, Aug 05, 2020 at 07:09:23AM +0000, Christophe Leroy wrote:
>> +/*
>> + * The macros sets two stack frames, one for the caller and one for the callee
>> + * because there are no requirement for the caller to set a stack frame when
>> + * calling VDSO so it may have omitted to set one, especially on PPC64
>> + */
>
> If the caller follows the ABI, there always is a stack frame. So what
> is going on?
Looks like it is not the case. See discussion at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/2a67c333893454868bbfda773ba4b01c20272a5d.1588079622.git.christophe.leroy@c-s.fr/
Seems like GCC uses the redzone and doesn't set a stack frame. I guess
it doesn't know that the inline assembly contains a function call so it
doesn't set the frame.
Christophe
Powered by blists - more mailing lists