mips: Do not include hi and lo in __SYSCALL_CLOBBERS for R6

  From: "Dragan Mladjenovic" <dmladjenovic@wavecomp.com>

GCC 10 (PR 91233) won't silently allow registers that are not architecturally
available to be present in the clobber list anymore, resulting in build failure
for mips*r6 targets in form of:
...
.../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target
  146 |  __asm__ volatile (      \
      |  ^~~~~~~

This is because base R6 ISA doesn't define hi and lo registers w/o DSP extension.
This patch provides the alternative definitions of __SYSCALL_CLOBBERS for r6
targets that won't include those registers.

	* sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (__SYSCALL_CLOBBERS): Exclude
	hi and lo from the clobber list for __mips_isa_rev >= 6.
	* sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h (__SYSCALL_CLOBBERS): Likewise.
	* sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h (__SYSCALL_CLOBBERS): Likewise.
---
 sysdeps/unix/sysv/linux/mips/mips32/sysdep.h     | 9 +++++++--
 sysdeps/unix/sysv/linux/mips/mips64/n32/sysdep.h | 9 +++++++--
 sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h | 9 +++++++--
 3 files changed, 21 insertions(+), 6 deletions(-)

-- 
1.9.1
  

On Tue, 19 Nov 2019, Dragan Mladjenovic wrote:

> From: "Dragan Mladjenovic" <dmladjenovic@wavecomp.com>
> 
> GCC 10 (PR 91233) won't silently allow registers that are not architecturally
> available to be present in the clobber list anymore, resulting in build failure
> for mips*r6 targets in form of:
> ...
> .../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target
>   146 |  __asm__ volatile (      \
>       |  ^~~~~~~
> 
> This is because base R6 ISA doesn't define hi and lo registers w/o DSP 
> extension. This patch provides the alternative definitions of 
> __SYSCALL_CLOBBERS for r6 targets that won't include those registers.

What is the kernel ABI on r6 systems with the DSP extension - does the 
kernel ABI permit the kernel to clobber those registers on syscall return 
or not?  This patch looks like it's only safe if the kernel guarantees it 
will never clobber those registers on r6 (or later), regardless of 
instruction set extensions present.

Also, this issue suggests that build-many-glibcs.py ought to include MIPS 
r6 configurations to detect such build issues.  It might not be a good 
idea to duplicate all 24 ABIs for r6 (I don't know how many of them make 
sense for r6 anyway), but at least one each of o32, n32 and n64 for r6 (if 
all those make sense for r6) would be a good idea.  (build-many-glibcs.py 
additions should be a separate patch.)
  

On 19.11.2019. 17:57, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Dragan Mladjenovic wrote:

>

>> From: "Dragan Mladjenovic" <dmladjenovic@wavecomp.com>

>>

>> GCC 10 (PR 91233) won't silently allow registers that are not architecturally

>> available to be present in the clobber list anymore, resulting in build failure

>> for mips*r6 targets in form of:

>> ...

>> .../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target

>>    146 |  __asm__ volatile (      \

>>        |  ^~~~~~~

>>

>> This is because base R6 ISA doesn't define hi and lo registers w/o DSP

>> extension. This patch provides the alternative definitions of

>> __SYSCALL_CLOBBERS for r6 targets that won't include those registers.

>

> What is the kernel ABI on r6 systems with the DSP extension - does the

> kernel ABI permit the kernel to clobber those registers on syscall return

> or not?  This patch looks like it's only safe if the kernel guarantees it

> will never clobber those registers on r6 (or later), regardless of

> instruction set extensions present.


The kernel is not allowed to use DSP ASE. From what I see the DSP state 
is not restored on syscall exit. Only some vendor specific extension are 
allowed in the kernel. From what I understand that on "happy path" 
kernel just saves some registers and relies on C ABI to preserve the 
rest. The use of hi and lo is result of them not being preserved across 
the function calls in C.

> Also, this issue suggests that build-many-glibcs.py ought to include MIPS

> r6 configurations to detect such build issues.  It might not be a good

> idea to duplicate all 24 ABIs for r6 (I don't know how many of them make

> sense for r6 anyway), but at least one each of o32, n32 and n64 for r6 (if

> all those make sense for r6) would be a good idea.  (build-many-glibcs.py

> additions should be a separate patch.)

>


That sounds fine. The r6 is nan2008/(by far hard-float) and most if not 
all distros are targeting little-endian, so we can start with 
o32/n32/n64 mips64el variant. We could add the big endian variants for 
the sake of the completes, but I would not suggest bothering with 
soft-float.

Will submit a separate patch for that.
  

On Tue, 19 Nov 2019, Dragan Mladjenovic wrote:

> > What is the kernel ABI on r6 systems with the DSP extension - does the
> > kernel ABI permit the kernel to clobber those registers on syscall return
> > or not?  This patch looks like it's only safe if the kernel guarantees it
> > will never clobber those registers on r6 (or later), regardless of
> > instruction set extensions present.
> 
> The kernel is not allowed to use DSP ASE. From what I see the DSP state 
> is not restored on syscall exit. Only some vendor specific extension are 
> allowed in the kernel. From what I understand that on "happy path" 
> kernel just saves some registers and relies on C ABI to preserve the 
> rest. The use of hi and lo is result of them not being preserved across 
> the function calls in C.

Thanks.  If this means the kernel always preserves hi and lo for r6, 
regardless of extensions available, then the patch is OK to commit.  Note 
that we no longer include GNU-style ChangeLog entries in commit messages.
  

On 19.11.2019. 19:20, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Dragan Mladjenovic wrote:
>
>>> What is the kernel ABI on r6 systems with the DSP extension - does the
>>> kernel ABI permit the kernel to clobber those registers on syscall return
>>> or not?  This patch looks like it's only safe if the kernel guarantees it
>>> will never clobber those registers on r6 (or later), regardless of
>>> instruction set extensions present.
>>
>> The kernel is not allowed to use DSP ASE. From what I see the DSP state
>> is not restored on syscall exit. Only some vendor specific extension are
>> allowed in the kernel. From what I understand that on "happy path"
>> kernel just saves some registers and relies on C ABI to preserve the
>> rest. The use of hi and lo is result of them not being preserved across
>> the function calls in C.
>
> Thanks.  If this means the kernel always preserves hi and lo for r6,
> regardless of extensions available, then the patch is OK to commit.  Note
> that we no longer include GNU-style ChangeLog entries in commit messages.
>

Thanks,

Committed as [1]. I left the ChangeLog anyway.

[1] 
https://sourceware.org/git/?p=glibc.git;a=commit;h=a2e487ce1c59d19345d9ecacc58de79febd869e4