> On Apr 27, 2016, at 7:26 PM, Szabolcs Nagy <szabolcs.n...@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
