-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: unaligned accesses on mips64 #46283
Comments
Thanks. Maybe we want to check alignment in https://tip.golang.org/src/cmd/compile/internal/reflectdata/alg.go#L47 for architectures that cannot do unaligned memory access. Or maybe we could use readUnaligned32/64 in memequalNN functions on those architectures. |
I don't understand this piece of code, my initial idea was to revert CL 297771, but I don’t know if it is feasible to do so now. I don't have a test environment, and the Upstream machine seems to be very busy, I'm also not familiar with mips64. If you are free, could you help fix it? Thank you.
I feel that the first method is better, because there may be similar codes elsewhere. |
FYI: I've run this test on linux/mips64x 1000 times and all passes. |
This program should fail on a machine that forbids unaligned accesses, regardless of CL 297771. @4a6f656c could you try it on your machine?
|
The other option to fix this is to forbid merging field comparisons in the generated eq functions, on architectures which can't do unaligned loads. Or do the merge but call |
Thanks - I expected that to be the case. My understanding is that the Linux kernel will silently patch up unaligned accesses, which means it will have a performance impact (e.g. one |
@randall77 - confirmed, this results in a SIGBUS with both an older and newer version of Go:
So I guess we've just exposed a pre-existing bug :) |
Change https://golang.org/cl/322150 mentions this issue: |
Change https://golang.org/cl/322151 mentions this issue: |
This is a different fix for #37716. Should help make the fix for #46283 easier, since we will no longer need to keep compiler-generated hash functions and the runtime hash function in sync. Change-Id: I84cb93144e425dcd03afc552b5fbd0f2d2cc6d39 Reviewed-on: https://go-review.googlesource.com/c/go/+/322150 Trust: Keith Randall <khr@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Both
test/abi/leaf.go
andtest/abi/spills4.go
currentlySIGBUS
onopenbsd/mips64
:This is due to an unaligned access, resulting from an
ld
instruction with an address that is not a multiple of 8:I've bisected this to:
Prior to that commit
test/abi/leaf.go
(although introduced later on) builds and runs, after that commit it fails. Note that this test probably passes onlinux/mips64
, although there will be a performance penalty due to the kernel handling the unaligned access fault. Unfortunately we do not runtest
on theopenbsd/mips64
builder for performance reasons.The text was updated successfully, but these errors were encountered: