public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "segher at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-99888-4-gZuHoTamGq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99888-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888 --- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Alan Modra from comment #8) > (In reply to Segher Boessenkool from comment #7) > > '-fpatchable-function-entry=N[,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 > 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. > > 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, 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. 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=n 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?
next prev parent reply other threads:[~2022-08-12 13:02 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-03 8:13 [Bug target/99888] New: " jakub at gcc dot gnu.org 2021-04-03 8:16 ` [Bug target/99888] " jakub at gcc dot gnu.org 2022-08-03 2:53 ` linkw at gcc dot gnu.org 2022-08-03 9:50 ` linkw at gcc dot gnu.org 2022-08-03 18:40 ` segher at gcc dot gnu.org 2022-08-04 8:20 ` linkw at gcc dot gnu.org 2022-08-11 6:59 ` i at maskray dot me 2022-08-11 9:00 ` linkw at gcc dot gnu.org 2022-08-11 15:27 ` segher at gcc dot gnu.org 2022-08-12 3:00 ` amodra at gmail dot com 2022-08-12 13:02 ` segher at gcc dot gnu.org [this message] 2022-08-24 7:13 ` linkw at gcc dot gnu.org 2022-08-24 7:18 ` linkw at gcc dot gnu.org 2022-09-30 12:18 ` cvs-commit at gcc dot gnu.org 2022-09-30 12:34 ` linkw at gcc dot gnu.org 2022-09-30 12:35 ` linkw at gcc dot gnu.org 2024-01-17 13:58 ` matz at gcc dot gnu.org 2024-01-18 5:41 ` linkw at gcc dot gnu.org 2024-01-20 17:17 ` pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99888-4-gZuHoTamGq@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).