On 05/01/18 17:26, Jeff Law wrote: > On 01/04/2018 11:20 AM, Joseph Myers wrote: >> On Thu, 4 Jan 2018, Richard Earnshaw wrote: >> >>> 1 - generic modifications to GCC providing the builtin function for all >>> architectures and expanding to an implementation that gives the >>> logical behaviour of the builtin only. A warning is generated if >>> this expansion path is used that code will execute correctly but >>> without providing protection against speculative use. >> >> Presumably it would make sense to have a standard way for architectures >> with no speculative execution to just use the generic version, but without >> the warning? E.g., split up default_inhibit_load_speculation so that it >> generates the warning then calls another function with the same prototype, >> so such architectures can just define the hook to use that other function? >> > Seems wise. There's still architectures that don't speculate or don't > speculate enough to trigger these problems. > > Jeff >
I'm in two minds about that. There are certainly cases where you might want to use the generic expansion as part of handling a case where you have a more standard speculation barrier; in those cases you might want to emit your barrier and then let the generic code expand and provide the logical behaviour of the builtin. However, if you don't have a barrier you need to ask yourself, will my architecture ever have an implementation that does do speculation? Unless you can be certain that it won't, you probably need to be warned that some code the programmer thinks might be vulnerable to spectre has not been compiled with that protection, otherwise if you run that code on a later implementation that does speculate, it might be vulnerable. Let me give an example, we use the generic code expansion if we encounter the builtin when generating code for Thumb on pre-ARMv7 devices. We don't have instructions in 'thumb1' to guard against speculation and we really want to warn users that they've done this (it might be a mistake in how they're invoking the compiler). I could add an extra parameter to the helper (bool warn_unimplemented), which would be true if called directly from the expanders, but would now allow back-ends to implement a trivial variant that just suppressed the warning. They could also then use the generic expansion if all that was needed was a subsequent fence instruction. R.