Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1618860pxa; Thu, 6 Aug 2020 11:42:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPHuAYZ1RhG2n6vvxEER2KHY2NxbXYFvPKjBNX+7P40YPQZNO56uXtcPssjHo+Mu8QHNmt X-Received: by 2002:a50:ee0a:: with SMTP id g10mr5097360eds.289.1596739320455; Thu, 06 Aug 2020 11:42:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596739320; cv=none; d=google.com; s=arc-20160816; b=TeJZIIULMGfD2Axo5ECFmdIdzS/v3wbvJeH+acrCy1XjAV1LOgm5ZaBoMyjCKyBLtN qhiwHj8+1AKm4nFRA2jmDpaKpBYu5jzyyy66DP1yzQcn3XWT+9W5VEOlp5QE9tMOlR1h FvpkaHIjuTJt6PoTezzPgYcUYwgccs9SxRMoWgirRFmaJhpkw6x8G88A4bNvrtJkNcKZ U/fXgcvXYzyVuOyOo1CilibzFx5A8lHF9RTf1lZcn6sKm6V/NbmxfsOfP6PWa/GXZvgJ MQdzecrIpSs6GopnJlbDFNekWoP0EQ6/Pm1XUmjqF3hUbvGECX1Hmp2PYwAp1BQoBYIF Oyow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=frB4Lx4SyXajOdLyZbTi3eA7CHag5njKTRo170qx/gQ=; b=GhcLwWcYRBzW7Osve2gpdkP+APVNWSzjnllVjCaLDQqBsQO3hC2s/Y8QC4EWtOmvE/ FQUjxfM9bLUyaTKU45dEih7uIJW7sjWWSazm9T2jfWDS69zkLgmJsr6jECewo/8sB6C5 g/9DXs+iv6/iilHNealc+93dDFms7RctJReVfv5D9XIzFParAoJHOP9X5ixaUueoxISn tMcD+fWKTM8PSEZsk+i1uXZMBiT+WzK3eEuLXtKTvxDOrmnQc/qjZANsw2Q8mH+QvVg3 o2qq0vuuXu+bxl1o8ZZCM/NxtICm0TIaPLGvQpvgB/r8tSwc5+e1yFzwKauI/AFvEPWy uwCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v25si3776293ejb.238.2020.08.06.11.41.38; Thu, 06 Aug 2020 11:42:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727078AbgHFSif (ORCPT + 99 others); Thu, 6 Aug 2020 14:38:35 -0400 Received: from gate.crashing.org ([63.228.1.57]:59882 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728053AbgHFSeW (ORCPT ); Thu, 6 Aug 2020 14:34:22 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 076IXI7v018034; Thu, 6 Aug 2020 13:33:18 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 076IXGtc018033; Thu, 6 Aug 2020 13:33:16 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 6 Aug 2020 13:33:16 -0500 From: Segher Boessenkool To: Michael Ellerman Cc: Christophe Leroy , Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , nathanl@linux.ibm.com, linux-arch@vger.kernel.org, arnd@arndb.de, linux-kernel@vger.kernel.org, Tulio Magno Quites Machado Filho , 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. Message-ID: <20200806183316.GV6753@gate.crashing.org> References: <2a67c333893454868bbfda773ba4b01c20272a5d.1588079622.git.christophe.leroy@c-s.fr> <878sflvbad.fsf@mpe.ellerman.id.au> <65fd7823-cc9d-c05a-0816-c34882b5d55a@csgroup.eu> <87wo2dy5in.fsf@mpe.ellerman.id.au> <20200805133505.GN6753@gate.crashing.org> <87r1sky1hm.fsf@mpe.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r1sky1hm.fsf@mpe.ellerman.id.au> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Thu, Aug 06, 2020 at 12:03:33PM +1000, Michael Ellerman wrote: > Segher Boessenkool writes: > > On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote: > >> Christophe Leroy 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