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
x/sys/unix: ptrace API assumes GOARCH(target) == GOARCH(host) #9739
Comments
Well, obviously there is nothing we can do about this particular API, because of Go 1 contract, but presumably we can add Ptrace(Get|Set)Regs(386|Amd64) on both 386 and amd64. Thoughts? |
Even with Go1 api freeze, golang.org/x/sys/unix can be fixed. |
Is it really unfixable without an API change? |
Well we can add more precise APIs, leaving the current one (assuming ARCH(target) == ARHC(host)) as is, but that's just adding stuff rather than fixing existing stuff, so I don't consider that as "fixing" anything. And as for adding stuff, we can add it in some other repository, it doesn't have to be inside syscall. |
Repurposed this to be about x/sys/unix. |
Change https://golang.org/cl/73555 mentions this issue: |
syscall.PtraceGetRegs uses syscall.PtraceRegs. syscall.PtraceRegs depends on the host, e.g. if your binary is linux/386 syscall.PtraceRegs has 16 registers. But it's possible to run that linux/386 on an amd64 kernel, and attach to an amd64 process. In that case, syscall.PtraceRegs is not good anymore because the amd64 variant has 26 registers.
I have found this while trying to debug an arm64 Go process using an arm Go debugger.
The text was updated successfully, but these errors were encountered: