Aurelien Jarno wrote:
quoted text
> H. Peter Anvin a écrit :
>> Michael Matz wrote:
>>>
>>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>>
>>>>> So I think gcc at least needs an *option* to revert to the old
>>>>> behavior,
>>>>> and there's a good argument to make it the default for now, at least
>>>>> for
>>>>> x86/x86-64 on Linux.
>>>> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0,
>>>> they have the same behaviour as Linux, that is they don't clear DF
>>>> before calling the signal handler.
>>> Sigh.  We could perhaps insert a cld for all functions which can be
>>> recognized as possible signal handlers and call other unknown or
>>> string functions.  But it's probably even faster to emit cld in front
>>> of the inline copies of mem functions again :-(
>>>
>> Well, there is a (slight) difference: you know that a called function
>> will not clobber your DF state; it's only the entry condition which is
>> imprecise.
>>
>> The best would be if this could be controlled by a flag, which we can
>> flip once kernel fixes has been around for long enough.
> 
> I have to agree there. Whatever the decision that gcc will take,
> distributions will reenable the old behaviour for some time for to allow
> upgrades from a previous version.
> 
> Providing a flag to switch the behaviour (whatever the default
> behaviour) will help a lot.

I think you've got the timescales wrong.  Anything that we do now in gcc will
take a while to percolate to the Linux distributions.  It is far quicker for
those distributions to fix their kernels as fast as possible.  By the time any
gcc fix is in the world all of this will be over.

I suppose one could apply the precautionary principle, but those systems that
don't update kernels won't update gcc either, so the solution won't work.

Andrew.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/