From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8BE38385840C; Fri, 12 Aug 2022 03:00:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BE38385840C From: "amodra at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry* Date: Fri, 12 Aug 2022 03:00:29 +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: amodra at gmail dot com 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2022 03:00:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99888 --- Comment #8 from Alan Modra --- (In reply to Segher Boessenkool from comment #7) > '-fpatchable-function-entry=3DN[,M]' > Generate N NOPs right at the beginning of each function, with the > function entry point before the Mth NOP. Bad doco. Should be "after the Mth NOP" I think. Or better written to avo= id the concept of a 0th nop. Default for M is zero, placing all nops after the function entry and before normal function prologue code. > The nops have to be consecutive. I hope you are making this statement based on an analysis of the purpose of having M nops before the entry point and N-M after the entry point, because= the documentation you are quoting doesn't take into account the fact that ELFv2 functions have two entry points. We don't have "the" entry point. I admit I didn't analyse -fpatchable-function-entry usage in any depth befo= re writing the patches in PR98125. All I did was look at the linux kernel to = the point of deciding that we want a patchable area after the local entry point= to catch all calls to the function. That would be what -fpatchable-function-entry=3Dn does for ELFv2, and I think we all agree on = that. Why would someone want nops before a function entry? Perhaps as space for a pointer. Or perhaps as the main patch area branched to from patched code a= fter the entry, to limit number of nops executed in an unpatched function. Or perhaps so that the function can be called by a trampoline or via function pointer, to select either some extra code replacing those nops or the normal function entry. I think that means M nops go before the global entry point= .=20 (Note that the patch area before a function could well duplicate the normal global entry code.) I agree with comment #5. nops *inside* the global entry code are a daft id= ea.=