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?

  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: link
Be 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).