8000 arm64架构下可以使用x10寄存器? · Issue #181 · agiledragon/gomonkey · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

arm64架构下可以使用x10寄存器? #181

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

Open
sleepsheeps opened this issue Apr 17, 2025 · 7 comments
Open

arm64架构下可以使用x10寄存器? #181

sleepsheeps opened this issue Apr 17, 2025 · 7 comments

Comments

@sleepsheeps
Copy link

看了go文档并没有说明可以用x10寄存器当作临时寄存器使用,想问一下选择x10寄存器的依据是什么呢?

@xhd2015
Copy link
xhd2015 commented Apr 17, 2025

@sleepsheeps 你在哪看到的文档?

@sleepsheeps
Copy link
Author

@sleepsheeps 你在哪看到的文档?

https://tip.golang.org/src/cmd/compile/abi-internal

@xhd2015
Copy link
xhd2015 commented Apr 17, 2025

@sleepsheeps 主要是因为超过10个64bit参数的函数较少,当然不排除有。

不过你提到的这个确实可能是一个缺陷,即不应该使用x10作为临时寄存器。

下面的例子展示了x10是被用来传参的 (go1.24)

package main

import "fmt"

//go:noinline
func test11Args(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10,a11  int) int {
	return a1 + a2 + a3 + a4 + a5 + a6 + a7 + a8 + a9 + a10 + a11
}

func main() {
	result := test11Args(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11)
	fmt.Println(result)
}
GOARCH=arm64 go build -gcflags="-N -l" -o __debug ./
GOARCH=arm64 go tool objdump -s "main.main" __debug
...
  test.go:11            0x100099800             b27f07e5                ORR $6, ZR, R5
  test.go:11            0x100099804             b2400be6                ORR $7, ZR, R6
  test.go:11            0x100099808             b27d03e7                ORR $8, ZR, R7
  test.go:11            0x10009980c             d2800128                MOVD $9, R8
  test.go:11            0x100099810             d2800149                MOVD $10, R9
  test.go:11            0x100099814             d280016a                MOVD $11, R10
  test.go:11            0x100099818             97ffffc6                CALL main.test11Args(SB)

@xhd2015
Copy link
xhd2015 commented Apr 17, 2025

@sleepsheeps 为什么你会提出这个问题?有什么特别的场景吗?

@sleepsheeps
Copy link
Author

@sleepsheeps 为什么你会提出这个问题?有什么特别的场景吗?

没有的,我最近也在研究go的热更,只是有这个疑问想问一下的。

@xhd2015
Copy link
xhd2015 commented Apr 17, 2025

@sleepsheeps 为什么你会提出这个问题?有什么特别的场景吗?

没有的,我最近也在研究go的热更,只是有这个疑问想问一下的。

有什么想法吗? gomonkey最大的问题是不线程安全。

我之前也有类似的想法,之前基于dlv做了一个尝试: xhd2015/delve#3

问题在于dlv依靠断点来暂停程序,太慢了。

后来,基于-exec/-overlay尝试了一下,目前只能函数拦截,但是做不到完全替换.

https://github.com/xhd2015/xgo

不过,我觉得热更新应该可以用这种思路实现。可能需要加个锁或者gc stop world

@sleepsheeps
Copy link
Author

@sleepsheeps 为什么你会提出这个问题?有什么特别的场景吗?

没有的,我最近也在研究go的热更,只是有这个疑问想问一下的。

有什么想法吗? gomonkey最大的问题是不线程安全。

我之前也有类似的想法,之前基于dlv做了一个尝试: xhd2015/delve#3

问题在于dlv依靠断点来暂停程序,太慢了。

后来,基于-exec/-overlay尝试了一下,目前只能函数拦截,但是做不到完全替换.

https://github.com/xhd2015/xgo

不过,我觉得热更新应该可以用这种思路实现。可能需要加个锁或者gc stop world

刚开始研究还没有想法呢。我也觉得不安全,但是老板还是要这么搞。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
0