This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] mips: Do not include hi and lo in __SYSCALL_CLOBBERS for R6


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]