From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112980 --- Comment #15 from Kewen Lin --- (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)?!=