Re: glibc 2.31: hard freeze on Friday, 31st Jan

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 31/01/2020 09:49, Florian Weimer wrote:
> * 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.

My understanding from the thread discussion was that some our assumptions
about local register variables was not in par with gcc documentation. 
What I am not sure is if the gcc documentation made it more clear or
actually changed its semantic over the releases.

> 
> 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).

Again my understanding from Segher Boessenkool explanation is GCC does
provide such semantic for local register variables.  I am not fully sure
what is causing sparc32 issues here, but nonetheless it is still a
*regression* that I would prefer to not release the glibc with it.  

I am currently testing a fix where I simplify a bit the sparc kernel
ABI call by not use 'g1' as the error indication, but rather using
the default Linux syscall ABI where negative value between -1 and
-4096 indicates an error (as for majority of architectures do).