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 88B8C3858D39; Wed, 10 Apr 2024 02:14:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88B8C3858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712715282;
	bh=9pZASd1IfTn8USMXI4dEjt1dhn689Rq4Z/FcBQXi3FM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SYO1JvKkammVScycYfkLQbTGqmKnQe32x4/ooNEYHgBT9W1HyRAuZmFz3r0bmuyfG
	 bMAZqIBrGpHpc0pDR3ZRbWEIDrEffXdNsphJVDdbSHL/L2bOoaRYUkXEW0BO0ChAfT
	 s2yPrTvkEV4OD+Walj4LyhXD+QVThEs+PSHWlLPk=
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: Wed, 10 Apr 2024 02:14:40 +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-TCmgBfUkZY@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 #15 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #14)
> Hmm?  But this is not how the global-to-local hand-off is implemented (and
> expected by tooling): a fall-through.  The global entry sets up the GOT
> register, there simply is no '[b localentry]'.
>=20
> If you mean to imply that also the '[b localentry]' should be patched in =
at
> live-patch application time (and hence the GOT setup would need to be mov=
ed
> to still somewhere else), then you have the problem that (in the
> not-yet-patched=20
> case) as long as the L1-nops sit between global and local entry they will
> always=20
> be executed when the global entry is called.

Sorry for confusion, I meant the sequence like:

global entry:
  [TOC base setup] // always here
  [b localentry] // which is added when patching
L1:
  [patched code] // from patching
  localentry:=20
  [b L1]         // from patching

> That's wasteful.

I agree, nops are not zero cost on Power8/Power9.

>=20
> Additionally tooling will be surprised if the address difference between
> global and local entry isn't exactly 8 (i.e. two instructions).  The psABI
> allows for different values, of course.  But I'm willing to bet that there
> are
> bugs in the wild when different values would be actually used.
>=20

It's possible that some tooling doesn't conform the ABI doc well, but I thi=
nk
the tooling should fix itself if that is the case. :)

> So, the nops-between-gep-and-lep could probably be somehow made to work w=
ith
> userspace live patching, but your most recent patch here makes this all m=
ood.
> It generates exactly the sequence we want: a single nop at the LEP, and
> a configurable patching area outside of, but near to, the function (here:=
 in
> front of the GEP).

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)?!=