"Paul Murphy" [off-list ref] writes:
(My apologies for however IBM's email client munges this)
quoted
I heard it is going to be in Go 1.16.7, but I do not know much about Go.
Maybe the folks in Cc can chime in.
We have backports primed and ready for the next point release. They
are waiting on the release manager to cherrypick them.
OK good, that is still the correct fix in the long run.
I think we were aware that our VDSO usage may have exploited some
peculiarities in how the ppc64 version was constructed (i.e hand
written assembly which just didn't happen to clobber R30).
Yeah I was "somewhat surprised" that Go thought it could use r30 like
that across a VDSO call :D
But to be fair the ABI of the VDSO has always been a little fishy,
because the entry points pretend to be a transparent wrapper around
system calls, but then in a case like this are not.
Go up to this point has only used the vdso function __kernel_clock_gettime; it
is the only entry point which would need to explicitly avoid R30 for
Go's sake.
I thought about limiting the workaround to just that code, but it seemed
silly and likely to come back to bite us. Once the compilers decides to
spill a non-volatile there are plenty of other ones to choose from.
cheers
On Mon, 2021-08-02 at 16:18 +1000, Michael Ellerman wrote:
But to be fair the ABI of the VDSO has always been a little fishy,
because the entry points pretend to be a transparent wrapper around
system calls, but then in a case like this are not.
This is somewhat debatable :-) If your perspective is from an
application, whether your wrapper is glibc, the vdso or *** knows what
else, you can't make assumptions about the state of the registers on a
signal hitting somewhere in your call chain other than what's
guanranteed by the ABI overall (ie, TLS etc...).
Nowhere was it written that a VDSO call behaved strictly like an sc
instruction :-)
quoted
Go up to this point has only used the vdso function __kernel_clock_gettime; it
is the only entry point which would need to explicitly avoid R30 for
Go's sake.
I thought about limiting the workaround to just that code, but it seemed
silly and likely to come back to bite us. Once the compilers decides to
spill a non-volatile there are plenty of other ones to choose from.
Yeah fine graining this is a waste of time, I agree. Just stick with
fixing r30 for the whole vdso, it won't actually hurt, just make sure
this is somewhat documented as to why we do it (I don't remember what
you patch does off hand, I assume at least your git commit has all the
data, a comment near the offending line in the Makefile might be good
too).
Cheers,
Ben.
On Mon, Aug 02, 2021 at 04:18:58PM +1000, Michael Ellerman wrote:
quoted
Go up to this point has only used the vdso function __kernel_clock_gettime; it
is the only entry point which would need to explicitly avoid R30 for
Go's sake.
I thought about limiting the workaround to just that code, but it seemed
silly and likely to come back to bite us. Once the compilers decides to
spill a non-volatile there are plenty of other ones to choose from.
It can be cheaper to spill N..31 consecutively, using stmw for example.
For 64-bit Power implementations it doesn't currently make any
difference. Since none of this will be inlined it doesn't have any real
impact.
(This also happens with -m32 -fpic, which always sets GPR30 as fixed, it
is the offset table register. With those flags -ffixed-r30 doesn't do
anything btw (r30 already *is* a fixed function register), and this will
not work with a Go that clobbers r30. But this is academic :-) )
Segher
Fixes will be in Go 1.16.7 and 1.15.15. Backports are no longer being
done for Go 1.14.
On 8/2/21 1:18 AM, Michael Ellerman wrote:
"Paul Murphy" [off-list ref] writes:
quoted
(My apologies for however IBM's email client munges this)
quoted
I heard it is going to be in Go 1.16.7, but I do not know much about Go.
Maybe the folks in Cc can chime in.
We have backports primed and ready for the next point release. They
are waiting on the release manager to cherrypick them.
OK good, that is still the correct fix in the long run.
quoted
I think we were aware that our VDSO usage may have exploited some
peculiarities in how the ppc64 version was constructed (i.e hand
written assembly which just didn't happen to clobber R30).
Yeah I was "somewhat surprised" that Go thought it could use r30 like
that across a VDSO call :D
But to be fair the ABI of the VDSO has always been a little fishy,
because the entry points pretend to be a transparent wrapper around
system calls, but then in a case like this are not.
quoted
Go up to this point has only used the vdso function __kernel_clock_gettime; it
is the only entry point which would need to explicitly avoid R30 for
Go's sake.
I thought about limiting the workaround to just that code, but it seemed
silly and likely to come back to bite us. Once the compilers decides to
spill a non-volatile there are plenty of other ones to choose from.
cheers