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 PM 08:33
>To: Jaydeep Patil
>Cc: musl@lists.openwall.com
>Subject: Re: [musl] [PATCH] Fix atomic_arch.h for MIPS32 R6
>
>On Wed, Mar 23, 2016 at 06:37:41AM +0000, Jaydeep Patil wrote:
>> >-----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.
>
>If R6 doesn't even try to be compatible with pre-R6 then I think we should
>treat it as a separate subarch and add "r6" in the dynamic linker name, either
>before or after the optional "el" component. Is there some general
>documentation of this incompatibility? How do GCC and binutils handle it? Are
>the ELF files flagged incompatible somehow?

There is no document which talks about this incompatibility particularly.
The e_flags member of the ELF header has two new flags (E_MIPS_ARCH_32R6 and E_MIPS_ARCH_64R6) added for R6.
We can choose to add "r6" in the dynamic linker's name.

>> >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..
>
>How can you assume the offset will be 0? It's the compiler's choice what to
>use. For instance, a_cas(&foo->bar, t, s) is likely to have an offset equal to
>offsetof(__typeof__(foo),bar). AFAIK this happens in practice with small
>offsets in mutex structures, etc. so the bug may be unlikely to be hit, but I
>think it's still an incorrect-constraint bug.

Compiler generates appropriate LL/SC based on the offset. 
Compiler adds the offset to the base register if it does not fit 9bits.

>Rich