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 A6517385841E; Tue,  9 Apr 2024 12:59:34 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A6517385841E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1712667574;
	bh=Iou/0XJG0ZpA+XqQrCH1oqAgkQrbkDUsC9I57hU5f8Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=v9fw/4c4anDclWbF3PPIx283JHuZ273xfEQ8lI3sFDYY6y0TiEejee+BWkeMAXOUH
	 bwDOuO0cPOKmgw4u05TCJ9TRBaptTDuKoeMI5uaJYfx6reoIEFDxbgTybG6cGXHcyc
	 rnXTi5qYE+PwTudySScenoqIk3ZKAWpLUHFwDw4o=
From: "matz 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: Tue, 09 Apr 2024 12:59:32 +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: matz 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-v8O8tXw2aH@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 #14 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #13)
> (In reply to Giuliano Belinassi from comment #12)
> > With your patch we have:
> >=20
> > > .LPFE0:
> > > ...
> > Which seems what is expected.
>=20
> Hi Giuliano, thanks for your time on testing it!  Could you kindly help to
> explain a bit on why "In such way we can't use the this space to place a
> trampoline to the new function"? Is it due to inefficient code like needi=
ng
> more branches?
>=20
> global entry:
>   [b localentry]
> L1:
>   [patched code]
> localentry:
>   [b L1]
>=20
> Or some other reason which makes it unused at all?

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]'.

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 moved
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.  That's wasteful.

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.

So, the nops-between-gep-and-lep could probably be somehow made to work with
userspace live patching, but your most recent patch here makes this all moo=
d.
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).=