From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F0DB93858D28; Fri, 12 Aug 2022 13:02:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F0DB93858D28 From: "segher at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry* Date: Fri, 12 Aug 2022 13:02:33 +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: segher 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 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 13:02:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99888 --- Comment #9 from Segher Boessenkool --- (In reply to Alan Modra from comment #8) > (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. >=20 > Bad doco. Should be "after the Mth NOP" I think. Or better written to > avoid the concept of a 0th nop. Default for M is zero, placing all nops > after the function entry and before normal function prologue code. It is correct as written? Also, "M" isn't used in the current compiler (and *cannot* be used: it is a local variable that goes out of scope after being set, patch_area_start in process_options). [The text is carefully written so that "anywhere before the Mth nop" will be a valid implementation as well, btw, that perhaps explains the tortured language here. But maybe there is another explanation for that). > > The nops have to be consecutive. >=20 > I hope you are making this statement based on Based on just what is written. "N nops right at the beginning of the function". Not very formal, but not open to other interpretations either. > an analysis of the purpose of > having M nops before the entry point and N-M after the entry point, becau= se > 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. If ELFv2 wants to do something with the LEP here, it should make some extra flag here. Abusing generic facilities for a different purpose never works. > I admit I didn't analyse -fpatchable-function-entry usage in any depth > before 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. The PowerPC Linux kernel uses -mprofile-kernel instead, which works a lot better for them AFAIUI. Are people planning on changing that?=