[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

["amodra at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888

--- Comment #8 from Alan Modra <amodra at gmail dot com> ---
(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.

> The nops have to be consecutive.

I hope you are making this statement based on 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.

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.

Why would someone want nops before a function entry?  Perhaps as space for a
pointer.  Or perhaps as the main patch area branched to from patched code after
the entry, to limit number of nops executed in an unpatched function.  Or
perhaps so that the function can be called by a trampoline or via function
pointer, to select either some extra code replacing those nops or the normal
function entry.  I think that means M nops go before the global entry point. 
(Note that the patch area before a function could well duplicate the normal
global entry code.)

I agree with comment #5.  nops *inside* the global entry code are a daft idea.