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.
