[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160322212211.GG21636@brightrain.aerifal.cx>
Date: Tue, 22 Mar 2016 17:22:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [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/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
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.
