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

[Jaydeep Patil <Jaydeep.Patil@imgtec.com>]

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 23 March 2016 AM 02:52
>To: musl@lists.openwall.com
>Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6
>
>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/do
>> cumentation/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

R6 is not binary compatible with pre-R6.

>seem to be any info here specific to LL/SC, and the page 209 you cited is really
>sparse.

It is page 219 which talks about R6 and pre-R6 LL opcodes. 

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

The "m" constrain is still valid here, as the offset will be 0 in this case.

>Rich