Received-SPF: pass (google.com: domain of linux-kernel+bounces-72599-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240206074552.541154-1-maskray@google.com> <CAMuHMdVOoxVFohcwwoQtY0KgZEvbjgJJ6mib8Fabo97P0krEqw@mail.gmail.com>
 <CAMj1kXGaF5bobHTr1pTg+-=s4Ft7+5SSbX72-NxsR_W_Yuxb8Q@mail.gmail.com>
 <CAMj1kXGw+r7yEEBA8gYBcdrqkiP=VYOSzz9YLnNavJn2snmFwA@mail.gmail.com>
 <CAMuHMdX+6fnAf8Hm6EqYJPAjrrLO9T7c=Gu3S8V_pqjSDowJ6g@mail.gmail.com>
 <CAMj1kXHh_m=V0QsiTpHrUXpFBXFbFfezdysz8quhPSgUrZg1MA@mail.gmail.com>
 <dca5b082-90d1-40ab-954f-8b3b6f51138c@app.fastmail.com> <ZdOcXTvvHyl8s56I@FVFF77S0Q05N>
 <CAMj1kXGWiTusoFWPCwM9OVwxp5=BHPfUdG-CurO13mWOdQr6Hg@mail.gmail.com>
In-Reply-To: <CAMj1kXGWiTusoFWPCwM9OVwxp5=BHPfUdG-CurO13mWOdQr6Hg@mail.gmail.com>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Tue, 20 Feb 2024 09:49:58 +0100
Message-ID: <CAMj1kXFK6nf3YM8d0Tfn+yBRnHCrNj3rGON9pdV7EuCGPEVpTg@mail.gmail.com>
Subject: Re: [PATCH v2] arm64: jump_label: use constraints "Si" instead of "i"
To: Mark Rutland <mark.rutland@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Geert Uytterhoeven <geert@linux-m68k.org>, 
	Fangrui Song <maskray@google.com>, Catalin Marinas <catalin.marinas@arm.com>, 
	Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org, 
	Jisheng Zhang <jszhang@kernel.org>, Dave Martin <Dave.Martin@arm.com>, 
	Peter Smith <peter.smith@arm.com>, llvm@lists.linux.dev, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 20 Feb 2024 at 08:55, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 19 Feb 2024 at 19:22, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Mon, Feb 19, 2024 at 06:06:19PM +0100, Arnd Bergmann wrote:
> > > On Mon, Feb 19, 2024, at 16:41, Ard Biesheuvel wrote:
> > > > On Mon, 19 Feb 2024 at 15:43, Geert Uytterhoeven <geert@linux-m68k.=
org> wrote:
> > > >> On Mon, Feb 19, 2024 at 11:57=E2=80=AFAM Ard Biesheuvel <ardb@kern=
el.org> wrote:
> > > >> > On Mon, 19 Feb 2024 at 11:56, Ard Biesheuvel <ardb@kernel.org> w=
rote:
> > >
> > > >> > https://godbolt.org/z/GTnf3vPaT
> > > >>
> > > >> I could reproduce the issue on v6.8-rc5 using arm64 defconfig
> > > >> and x86_64-gcc-5.5.0-nolibc-aarch64-linux.tar.xz from
> > > >> https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/5.5.0/=
:
> > > >>
> > > >
> > > > OK, I managed to do so as well.
> > > >
> > > > And GCC 6.4 from the same source works correctly.
> > > >
> > > > Not sure whether there are any plans to bump the minimal GCC versio=
n
> > > > any time soon (cc'ing Arnd), but we should probably drop this chang=
e
> > > > until that happens.
> > >
> > > From what I can tell, we may as well formally raise the minimum
> > > gcc version to 8.1+ already, as that is a version that is
> > > actually used in distros, and we have been on 5.1+ for a few
> > > years already.
> > >
> > > Not sure if there are any other benefits to gcc-8 besides
> > > allowing minor cleanups.
> >
> > Arguably a minor cleanup, but on arm64 that'd allow us to get rid of th=
e old
> > mcount-based ftrace implementation and rely on -fpatchable-function-ent=
ry.
> > On its own that'd save ~130 lines of asm and ~70 lines of C, but it'd a=
lso
> > remove some constraints on other features (e.g. the mcount-based form's=
 graph
> > tracer isn't compatible with pointer authentication), it would simplify=
 a few
> > things going forwards (e.g. the implementation of RELIABLE_STACKTRACE, =
since we
> > could rely on having ftrace_regs and a single trampoline), and the rema=
ining
> > support would be better tested.
> >
> > I've wanted to remove the old ftrace implementation for a while, but on=
 its own
> > it was never important/urgent enough to justify bumping to GCC 8+.
> >
>
> I don't think this is minor, tbh. Supporting two versions of the
> highly complex tracing infrastructure for a toolchain that is only
> used in CI seems like a waste of time and effort.
>
> I checked x86, and it needs at least GCC 7 for retpoline support, so I
> reckon at least GCC 5/6 support might be dropped there as well.

Another data point: __GCC_ASM_FLAG_OUTPUTS__ needs GCC 6 or later on x86.