On Mon, Sep 26, 2011 at 11:56 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 26 September 2011 12:43, Jan Kiszka <jan.kis...@siemens.com> wrote: >> On 2011-09-26 13:33, Peter Maydell wrote: >>> On 26 September 2011 11:51, Jan Kiszka <jan.kis...@siemens.com> wrote: >>>> This increases the overhead of frequently executed helpers. We need to >>>> move rule past QEMU_CFLAGS assignment to ensure that the required simple >>>> assignment picks up all bits. The signal workaround is moved just for >>>> the sake of consistency. >>> >>>> +# NOTE: Must be after the last QEMU_CFLAGS assignment >>>> +op_helper.o user-exec.o: QEMU_CFLAGS := $(subst >>>> -fstack-protector-all,,$(QEMU_CFLAGS)) $(HELPER_CFLAGS) >>> >>> Why also user-exec.o ? >> >> That's a good question. It doesn't look like it's deserving this. >> >>> Why not the other source files with helpers in? >> >> Name them and I add them. > > target-*/*helper.c ? > > But mostly I think what I'm trying to say is that this is making > a tradeoff between safety and speed, so it ought to come with a > rationale for why it is OK to remove the safety checks for these > files. Given that rationale you can identify other files that are > also safe/worthwhile to flip the flag for.
I wouldn't remove -fstack-protector-all by default. Especially op code interfaces with the guest. For max performance version, I'd check if -fomit-frame-pointer and -O3 makes sense. See also this article: https://www.debian-administration.org/article/672/Optimizing_code_via_compiler_flags >>> (Or to not >>> have -fstack-protector-all globally?) >> >> Opt-in instead of opt-out, that might be some approach, though I bet the >> out-out set still bets the opt-in crowed by some orders of magnitude. > > Have you looked at whether using plain -fstack-protector for all files > (rather than the -all version) helps? Presumably we had some reason for > picking the -all version though... > > -- PMM >
