[PATCH] tst-setcontext2: avoid bug from compiler optimization

[Florian Weimer]

On 01/27/2017 10:53 PM, Chris Metcalf wrote:
> On 1/27/2017 4:30 PM, Florian Weimer wrote:
>> On 01/27/2017 09:34 PM, Chris Metcalf wrote:
>>> I'd like to commit the one-line patch below that just declares the
>>> context
>>> variables for test-setcontext2 as static.  I think the consensus is that
>>> this is necessary,
>>
>> No, I think the test is supposed to work as-is; it is valid.
>>
>> So if this test is broken, it is a bug in the implementation of the
>> context switching functions (as they are visible to applications, i.e.
>> the fix might not be in the functions themselves, but adjusting their
>> calling conventions, inhibiting GCC optimizations which make incorrect
>> assumptions, etc.).
>>
>> If we do not have a fix right now, it is better to let the test keep
>> failing (perhaps XFAIL it), rather than tweaking it so that it tests
>> something else.
>
> We would be waiting on functionality from gcc that doesn't currently
> exist, correct?  The current returns_twice semantics is insufficient to
> describe the problem that we currently see with shared stack frames.

I think this could still be a GCC regression in the handling of the 
returns_twice attribute, introduced when GCC started sharing stack slots 
more aggressively.  When returns_twice was initially implemented and 
documented, the question of stack slot reuse did not arise because GCC 
probably did not do it at all.

> It's possible that returns_twice could be extended to also have the
> semantics of "don't share my arguments' stack space with any other
> variables in this function" pretty reasonably, but I don't want to try to
> guess what will make most sense to the gcc folks.

GCC already has this behavior on x86_64.  This could be an accident.

> I can certainly let the test keep failing and just open a bug to reference
> it and capture some of this discussion.

Yes, would you please file a GCC bug with a preprocessed input file?

Thanks,
Florian