[lkml]   [2019]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH for 5.2 10/10] rseq/selftests: mips: use break instruction for RSEQ_SIG
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.


 \ /
  Last update: 2019-04-30 00:33    [W:0.068 / U:1.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site