Re: [PATCH] add -fprolog-pad=N option to c-family

[Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>]

> On Apr 27, 2016, at 7:26 PM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> 
> On 27/04/16 16:22, Torsten Duwe wrote:
>> Hi Maxim,
>> 
>> thanks for starting the work on this; I have added the missing
>> command line option. It builds now and the resulting compiler generates
>> a linux kernel with the desired properties, so work can continue there.
>> 
>> 	Torsten
> 
> i guess the flag should be documented in invoke.texi
> 
> it's not clear what N means in -fprolog-pad=N, how
> location recording is enabled and how it interacts
> with -fipa-ra. (-pg disables -fipa-ra, but -fprolog-pad
> works without -pg.)

I think, it should be responsibility of the user to disable -fipa-ra if code intended to be patched-in will be incompatible with IPA-RA.  I agree, though, that documentation of -fprolog-pad= should make a special note of this fact and recommend inclusion of -fno-ipa-ra to the cflags whenever -fprolog-pad= is used..

> 
> with -mfentry, by default the user only has to
> implement the fentry call (linux wants nops there, but
> e.g. glibc could use -pg -mfentry for profiling on
> aarch64 and the target specific details are easier to
> document for an -m option than for something general).

I don't understand your point here, could you elaborate, please?

> 
> the nop-padding is more general, but the size and
> layout of nops and the call abi will be target
> specific and the user will most likely need to modify
> the binary (to get the right sequence) which needs
> additional tooling.  i don't know who might use it
> other than linux (which already has tools to deal with
> -mfentry).

Right, but this tooling will require minimal (if any) changes to be adapted to nop-pad approach.  If I remember correctly, recent versions of GCC and kernel for x86_64 generate NOPs, not the call sequence in the prologs when -mfentry is used.

> 
> i'm not against nop-padding, but i think more evidence
> is needed that the generalization is a good idea and
> users can deal with the resulting issues.

--
Maxim Kuvyrkov
www.linaro.org