[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BD7773622145634B952E5B54ACA8E349AA24BAFA@PUMAIL01.pu.imgtec.org>
Date: Mon, 28 Mar 2016 05:07:39 +0000
From: Jaydeep Patil <Jaydeep.Patil@...tec.com>
To: Rich Felker <dalias@...c.org>
CC: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: [PATCH] Fix atomic_arch.h for MIPS32 R6
>-----Original Message-----
>From: Rich Felker [mailto:dalias@...ifal.cx] On Behalf Of Rich Felker
>Sent: 23 March 2016 PM 08:33
>To: Jaydeep Patil
>Cc: musl@...ts.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@...ifal.cx] On Behalf Of Rich Felker
>> >Sent: 23 March 2016 AM 02:52
>> >To: musl@...ts.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@...ifal.cx] On Behalf Of
>> >> >dalias@...c.org
>> >> >Sent: 21 March 2016 PM 11:08
>> >> >To: musl@...ts.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
