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 A455A3858D33; Fri, 12 Apr 2024 03:48:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A455A3858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712893733;
	bh=tk5sxQUbnK6ih11KXe2efBWJVRnWrwMxT/tRHzJcw64=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=PS9mzrzkHoBaF+/nm3EcdFgqyUIKnbkP5pHbLB0RRPwjgAZlH1QO43SbZy0BTcYnc
	 0wEgCNIvjwmUHhS5bV+zIHcPIDzw0USv+T62NCuTCxL8ltVX5h8p5StVqv9+llpT3t
	 9uP+OM+SUeFzwvi4NnWuMmW6QQvkVh+nTSFNWZZ0=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be
 generated before function global entry point
Date: Fri, 12 Apr 2024 03:48:51 +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: 13.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
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-112980-4-QXOxyDhKSw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112980-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112980-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=3D112980

--- Comment #17 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #16)
> (In reply to Kewen Lin from comment #15)
> > I agree, thanks for the comments! btw, I'm not fighting for the current
> > implementation, just want to know more details why users are unable to =
make
> > use of the current implementation, is it just due to its inefficiency (=
like
> > the above sequence) or un-usability (unused at all). As your comments, I
> > think it's due to the former (inefficiency)?!
>=20
> Okay.  So, yeah, I _think_ that other way (with NOPs between GEP and LEP,
> plus a jump around them) could be made to work with userspace live patchi=
ng.
> It would just be inefficient.  But do note that that jump around was _not_
> part of the original way of -fpatchable-function-entry, so a change to
> codegen
> would have to have happened anyway to make that other way usable.  And it
> has the
> (perhaps theoretical, who knows :) ) problem of not using the normal 8-by=
te
> difference between GEP and LEP.
>=20

Thanks again for confirming this understanding!

> I think your current proposal from comment #10 is the better from all
> perspectives.

Yeah, I agree. When reworking this support previously, comment #10 like
implementation was considered as a better one but it's not finally made due=
 to
the concern that can break the assumption NOPs should be consecutive, based=
 on
all the inputs here I think it's time to "fix" it by just underscoring this
special not-consecutive NOPs in documentation.=