From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 247033858C60; Thu, 18 Jan 2024 05:41:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 247033858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1705556502;
	bh=qI9EKdCSNhYUCTcPh8+10I7ua7sclrYhUiILZSpCcTU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=AEIYg5VM8UPaI64NfR2c3o7zsf9Qxm2+uhLjfPSZJhY9crQnyTuPD0SnQCw54eGnQ
	 EEunXvrdlKPl+Zi8KyFE+8dz2kQ9XkpTl258crzi4GDLbKUF4PJJfY9h5J4aoaOdLL
	 STV7rZNUB9MdnrsUcYy2Zx9Xk1D/11PpKsazb7FU=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/99888] Add powerpc ELFv2 support for
 -fpatchable-function-entry*
Date: Thu, 18 Jan 2024 05:41:35 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99888-4-Kd0ExgcGnG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99888-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99888

--- Comment #16 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #15)
> Umm.  I just noticed this one as we now try to implement userspace live
> patching
> for ppc64le.  The point of the "before" NOPs is (and always was) that they
> are
> completely out of the way of patchable but as-of-yet unpatched functions.
>=20
> For ppc that means the "before" and "after" NOPs cannot be consecutive.  =
The
> two
> NOP sets being consecutive was never a design criteria or requirement.
>=20
> So, while the original bug is fixed by what was committed (local entry was
> skipping the patching-nops), the chosen solution is exactly the wrong one=
 :-/

Thanks for the input! Sigh, sorry that we picked up the wrong one :(, you m=
ay
have noticed that the main consideration to choose the current one is to ke=
ep
it align with the consecutive NOPs described by the documentation, we need a
separate command line option as Segher's review comment in
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600239.html. Now we h=
ave
PR112980 filed for the requested behavior, let's discuss how to support it
there.=