public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "linkw 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: Wed, 24 Aug 2022 07:13:50 +0000 [thread overview] Message-ID: <bug-99888-4-hHnrypJXq4@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 #10 from Kewen Lin <linkw at gcc dot gnu.org> --- By searching the history of this feature, I found its initial versions only proposed to place nops after the function entry, such as: v2[1], then it's requested to be more generic to handle some "exploited atomically" requirements for RISV arches. Please see the below quoted content posted by Jose for SPARC[2] and more [3] to extend it for preceding nops. " How is this supposed to be exploited atomically in RISC arches such as sparc? In such architectures you usually need to patch several instructions to load an absolute address into a register. If a general mechanism is what is intended I would suggest to offer the possibility of extending the nops _before_ the function entry point, like in: (a) nop ! Load address nop ! Load address nop ! Load address nop ! Load address nop ! Jump to loaded address. entry: (b) nop ! PC-relative jump to (a) save %sp, bleh, %sp ... So after the live-patcher patches the loading of the destination address and the jump, it can atomically patch (b) to effectively replace the implementation of `entry'. " So placing just only one nop after function entry and leaving multiple nops to be patched before function entry was meant to make it exploited atomically. I'm not sure if there will be this kind of requirement for future uses of this feature on ppc64le. If we assume there is, we need to consider if the current proposal can support it and even easily. With proposal 1) in #c1, that is to place nops before and after local entry point. It allows three kinds of counts for preceding nops: 2, 6 and 14. IMHO, the count 14 seems to be enough for most cases? But people can blame it's not flexible for all kinds of counts, and it can take more size if the required count doesn't perfectly match one allowable count. Besides, it can offer bad user experience when users port their workable cases here but get errors. With proposal in #5, it doesn't have the restriction on the count of preceding nops, it's a very good thing. The main concern is what Segher pointed out, the patched nops are concluded to be consecutive, in the initial versions it's more explicit as the option name is "prolog-pad". And the separated nop sequences are for different function entry points, not for "the" function entry. To offer more flexibility to users, proposal in #5 looks better, but it requires one documentation update by saying the particularity on ppc64le, that is dual entries and the patching way.
next prev parent reply other threads:[~2022-08-24 7:13 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 2022-08-24 7:13 ` linkw at gcc dot gnu.org [this message] 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-hHnrypJXq4@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).