This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] add -fprolog-pad=N option to c-family
- From: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Torsten Duwe <duwe at suse dot de>, nd at arm dot com, Li Bin <huawei dot libin at huawei dot com>, Jiri Kosina <jkosina at suse dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>
- Date: Thu, 28 Apr 2016 11:47:47 +0300
- Subject: Re: [PATCH] add -fprolog-pad=N option to c-family
- Authentication-results: sourceware.org; auth=none
- References: <20160427152217 dot GA2637 at suse dot de> <5720E81D dot 9060409 at arm dot com>
> 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