Re: [Qemu-devel] [PATCH v2] tcg: Remove stack protection from helper functions

[Blue Swirl]

On Mon, Sep 26, 2011 at 11:56 AM, Peter Maydell
<address@hidden> wrote:
> On 26 September 2011 12:43, Jan Kiszka <address@hidden> wrote:
>> On 2011-09-26 13:33, Peter Maydell wrote:
>>> On 26 September 2011 11:51, Jan Kiszka <address@hidden> 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
>