看起来像是某种内存损坏,尽管在N=1的情况下,我不清楚这个bug是否特定于netbsd或arm64,甚至是mips编译器后端中的某种奇怪的bug。😅(CC @golang/netbsd @golang/arm)
netbsd
arm64
mips
u0njafvf1#
在这部PC上,指令是
MOVHU 186(R5), R8 ORR $2, R8, R8 MOVH R8, 186(R5) JMP 804
这些指令确实包含这些字节,并且是有效的指令。所以代码生成并不糟糕。也许是一些内核的奇怪之处?或者是其他进程发送了一个SIGILL?(为什么?)或者是坏的I-cache?(打印出的字节可能是通过D-cache加载的。I-cache的内容可能不同。)
0tdrvxhp2#
这个指令看起来没问题。这是在netbsd/arm64上,使用该git哈希值编译的二进制文件的相应部分:
obj0.go:246 0x273d3c b4ff3ac5 CBZ R5, -1578(PC) obj0.go:247 0x273d40 794174a8 MOVHU 186(R5), R8 <- this one obj0.go:247 0x273d44 b27f0108 ORR $2, R8, R8
看起来指令解码器和实际内存在涉及的指令上不一致。这绝对像是某种形式的损坏。
2条答案
按热度按时间u0njafvf1#
在这部PC上,指令是
这些指令确实包含这些字节,并且是有效的指令。所以代码生成并不糟糕。也许是一些内核的奇怪之处?或者是其他进程发送了一个SIGILL?(为什么?)或者是坏的I-cache?(打印出的字节可能是通过D-cache加载的。I-cache的内容可能不同。)
0tdrvxhp2#
这个指令看起来没问题。
这是在netbsd/arm64上,使用该git哈希值编译的二进制文件的相应部分:
看起来指令解码器和实际内存在涉及的指令上不一致。这绝对像是某种形式的损坏。