Re: [RFC PATCH for 5.2 10/10] rseq/selftests: mips: use break instruction for RSEQ_SIG

[Paul Burton <paul.burton@mips.com>]

Hi Mathieu,

On Thu, Apr 25, 2019 at 10:21:32AM -0400, Mathieu Desnoyers wrote:
> I've tried to figure out if we could find a way to have RSEQ_SIG left undefined
> if it's not on the plain mips environment, but could not find anything that
> would be #defined on plain mips, but #undefined on both micromips and nanomips.
> 
> What I'd like to do is e.g.:
> 
> #if defined(__nanomips__)
> # ifdef __MIPSEL__
> #  define RSEQ_SIG	0x03500010
> # else
> #  define RSEQ_SIG	0x00100350
> # endif
> #elif defined(__mips_micromips)
> # ifdef __MIPSEL__
> #  define RSEQ_SIG	0xd4070000
> # else
> #  define RSEQ_SIG	0x0000d407
> # endif
> #elif defined(__mips__)
> # define RSEQ_SIG	0x0350000d
> #else
> /* Leave RSEQ_SIG as is. */
> #endif
> 
> The idea here is to not allow code targeting future MIPS ISA to compile
> with the wrong signature.
> 
> The delta between compiling without/with -mmicromips on a gcc-8 compiler
> is only:
> 
> > #define __mips_micromips 1
> 
> Some interesting delta when compiling for plain little-endian mips with
> gcc-8 compared to the nanomips compiler is:
> 
> < #define __mips__ 1
> < #define _mips 1
> < #define MIPSEL 1
> 
> > #define __nanomips__ 1
> 
> < #define __mips_isa_rev 2
> > #define __mips_isa_rev 6
> 
> So let's say we have a picomips introduced in the future, can we rely
> on it not defining __mips__ like the nanomips compiler does ? If so,
> my "#elif defined(__mips__)" approach would indeed leave RSEQ_SIG undefined
> as expected.
> 
> Thoughts ?

That seems like a reasonable approach to me. I don't think it'll be
guaranteed, but it'll give the best odds of the behavior you want.

If I recall correctly the reason for not defining __mips__ in the
nanoMIPS compiler was to force people to audit MIPS-specific code given
the scale of the changes in nanoMIPS - there are some incompatibilities
at the assembly level but more than that the ABI changes in multiple
ways from register assignment & calling convention to kernel-user struct
layouts & other things. If we were to build existing MIPS-specific code
as-is then some of this could lead to brokenness that the tools wouldn't
have a good way to detect & reject automatically, so making people audit
the code & add in the __nanomips__ check is a sort of safety measure.

So the likelihood of your code above picking up on any future ISA
changes will probably depend upon how incompatible they are, which seems
pretty sensible.

Thanks,
    Paul