直接引自Golang 网站:“ GDB 不太了解 Go 程序。堆栈管理、线程和运行时包含与执行模型足够不同的方面 GDB 预计它们会混淆调试器并导致即使在编译程序时也不正确的结果使用 gccgo。因此,虽然 GDB 在某些情况下很有用(例如,调试 Cgo 代码,或调试运行时本身),但它不是 Go 程序的可靠调试器,尤其是并发性高的程序。此外,它不是一个Go 项目优先解决这些困难的问题。 ”
我也知道一些项目,如IDAGolangHelper或其他脚本,以帮助已经建立的逆向工程工具(如Ghidra)解释 Golang 二进制文件。尽管如此,我想知道假设一个人更喜欢一个已经成功理解古怪的 Go 运行时的自包含调试工具,你会选择什么?另外,如果您对Radare2处理 Go 二进制文件的能力有任何评论,我将不胜感激。
编辑 1(问题澄清):假设在 x86_64 主机上工作,QEMU
考虑到ptrace
未在QEMU
用户模式下实现的事实,在我看来,系统模式是环境的重要组成部分。另一个因素显然是libc
实施。对于带有ld-musl-aarch64.so.1
解释器的动态链接二进制文件,这会添加一个 Linux 发行版musl
作为本机libc
实现,除非人们希望musl
在已经glibc
安装的发行版上构建。所以我想我的问题是您会向QEMU
Alpine添加哪些其他功能(或工具)?