public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "markalle at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/95692] PPC64, suspicious store in front of inline assembly section Date: Wed, 17 Jun 2020 05:43:52 +0000 [thread overview] Message-ID: <bug-95692-4-zGJwsXDzQ0@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-95692-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95692 --- Comment #2 from Mark Allen <markalle at us dot ibm.com> --- Hi, thanks for the input. I was figuring gcc should see the inline assembly modifying r2 and any function call out of intercept_munmap() would be doing the logical equivalent of saving the current r2, calling something where a different r2 might be used, then upon return restoring r2 to whatever it was when it left intercept_munmap(). But it sounds like you're saying gcc should be the exclusive manager of r2. And I get that the activity of making a function call isn't always going to be as linear as "save current r2, set r2 for whatever new context it's calling into, restore r2". I'm open to other solutions. For most alternatives I can think of, I can at least imagine potential gcc behavior that would conflict with us hacking r2, which I expect is why you're suggesting doing nothing but our own assembly from intercept_munmap() downward. That would be rough though, we'd definitely like to be able to call other functions from intercept_munmap(). The problem starts when we turn munmap into a branch into intercept_munmap. At that point r2 would have been set up as valid for munmap() but then we branched into intercept_munmap() which presumably needs its own r2. So far the best hack I can see is to put it all in the initial branch. Eg overwrite munmap not just with a branch to intercept_munmap, but replace r2 at that level (rather than at the start of intercept_munmap). That essentially puts both of the things that hack the state into the same location, after which the state is consistent for gcc to continue doing whatever it wants. I'm getting the impression this isn't going to receive a blessing as a "good" solution though. Any other ideas for a "least bad" solution if we want to be able to make function calls into other gcc-compiled functions from inside intercept_munmap()?
prev parent reply other threads:[~2020-06-17 5:43 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-15 21:53 [Bug inline-asm/95692] New: " markalle at us dot ibm.com 2020-06-15 22:05 ` [Bug inline-asm/95692] " pinskia at gcc dot gnu.org 2020-06-17 5:43 ` markalle at us dot ibm.com [this message]
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-95692-4-zGJwsXDzQ0@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).