Re: [PATCH] Fix atomic_arch.h for MIPS32 R6

[Rich Felker <dalias@libc.org>]

On Tue, Mar 22, 2016 at 04:58:51AM +0000, Jaydeep Patil wrote:
> >-----Original Message-----
> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of dalias@libc.org
> >Sent: 21 March 2016 PM 11:08
> >To: musl@lists.openwall.com
> >Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6
> >
> >On Mon, Mar 21, 2016 at 06:03:47AM +0000, Jaydeep Patil wrote:
> >> Hi Rich,
> >>
> >> The arch/mips/atomic_arch.h uses MIPS2 opcode for LL and SC
> >> instructions. Opcodes of these instructions differ on MIPSR6.
> >
> >Does this mean MIPSR6 is an incompatible ISA that can't run normal MIPS
> >binaries? If so that's a messy situation we need to find a way to deal with; if
> >the difference is just LLSC though then perhaps the kernel's emulation
> >handles it (albeit very slowly).
> >
> >
> >It would be helpful if you could provide a link to the documentation of this
> >issue (different opcodes).
> 
> Refer to
> https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MD00086-2B-MIPS32BIS-AFP-06.04.pdf
> (Page 209) for details.

Page 454 contains the best info I could find, which seems to say that
MIPS R6 is essentially a MIPS-incompatible ISA (it can't reliably
execute pre-R6 code). Is this correct? If so that's really
unfortunate. Unfortunately there does not seem to be any info here
specific to LL/SC, and the page 209 you cited is really sparse.

If this is really the case then we probably need to consider whether
some kind of awful runtime-switching mechanism is needed for baseline
MIPS ISA levels, or whether users just have to consider R6 "incapable
of running pre-R6 binaries". But in the latter case we might want to
use a different dynamic linker name for R6.

> >> arch/mips/atomic_arch.h | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/arch/mips/atomic_arch.h b/arch/mips/atomic_arch.h index
> >> ce2823b..16b1542 100644
> >> --- a/arch/mips/atomic_arch.h
> >> +++ b/arch/mips/atomic_arch.h
> >> @@ -3,9 +3,13 @@ static inline int a_ll(volatile int *p) {
> >>         int v;
> >>         __asm__ __volatile__ (
> >> +#if __mips_isa_rev < 6
> >>                 ".set push ; .set mips2\n\t"
> >> +#endif
> >>                 "ll %0, %1"
> >> +#if __mips_isa_rev < 6
> >>                 "\n\t.set pop"
> >> +#endif
> >
> >I think just the .set mips2 could be inside #ifdef with the push/pop always
> >used; that produces less #ifdef clutter. But first we need to figure out the
> >above issues.
> 
> We don't need push/pop if we are not doing mips2

I was just saying it makes the code less cluttered to use them
spuriously even though we don't need to:

		".set push ; "
#if __mips_isa_rev < 6
		".set mips2 ; "
#endif
		"ll %0, %1 ; .set pop"

or similar.

It's also not clear to me whether the "m" constraint is valid anymore
for the R6 ll/sc instructions since they take a 9-bit offset now
instead of a 16-bit offset. The compiler could generate an address
expression whose offset part does not fit in 9 bits. In that case we
may need to #if the whole function (or at least the __asm__ statement)
separately rather than just skipping the .set mips2...

Rich