glibc 2.31: hard freeze on Friday, 31st Jan

[Florian Weimer]

* Adhemerval Zanella:

> On 31/01/2020 09:12, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> Based on the extended asm and local register variable usage with GCC on
>>> the 'powerpc Linux scv support and scv system call ABI proposal' I think
>>> we hit a nasty latent sparc issue I am seeing at least on sparc32 tests
>>> (it clobbers the syscalls result and make some calls to clock_nanosleep
>>> to not act as a cancellation entrypoint).
>>>
>>> I am working on a solution, do you think we should push it after the
>>> release branch is created or can we hold a day or two?
>> 
>> I expect it will take considerable time for the GCC developers to agree
>> on the actual semantics of local register variables.  I do not think we
>> should hold the glibc release for it.  We can backport fixes as needed.
>
> I am seeing intermittent failures on some cancellation tests as reported
> on wiki:
>
> FAIL: nptl/tst-cancel18
> FAIL: nptl/tst-cancel22
> FAIL: nptl/tst-cancel23
> FAIL: nptl/tst-cancel4
> FAIL: nptl/tst-cancel5
> FAIL: nptl/tst-cancel7
> FAIL: nptl/tst-cancelx18
> FAIL: nptl/tst-cancelx4
> FAIL: nptl/tst-cancelx5
> FAIL: nptl/tst-cancelx7
>
> And based on the thread I do think we are doing some not fully supported
> on sparc that we can mitigate with more concise syscall code. In any case
> if you think this is not worth, we can backport it for sure.

I think local register variables are currently ill-defined on all
architectures.  Getting past that will take a lot of time.

I think the sparc32 assembler would actually be okay if GCC actually
implemented the new model (where local register variables reside in
specific registers if used in asm operands, but behavior like ordinary
local variables otherwise).

Thanks,
Florian