美好的一天！
我正在玩一个 C 项目。它位于 FreeBSD 机器上（看起来像 Raspberry PI2，不确定）
问题是我想在 Valgrind 中运行项目以查找内存泄漏。当我尝试通过端口安装 Valgrind 时，出现下一个错误：
root@raspberry-2-55:/usr/ports/devel/valgrind # make
===> valgrind-3.10.1.20160113,1 is only for i386 amd64, while you are running
armv6.
*** Error code 1
Stop.
make: stopped in /usr/ports/devel/valgrind
请帮助在这个平台上运行 valgrind。
【问题讨论】：
标签： valgrind freebsd raspberry-pi2
不支持 ARM6/FreeBSD 的组合。
valgrind 团队 doesn't support FreeBSD at all 和维护 FreeBSD port 的人员将其限制为 i386 和 AMD64，因为这些是当前的 Tier 1 架构。 更新：从 2021 年和 FreeBSD 13.0 开始，i386 将成为第二层。
据推测，直到 ARM 成为第 1 层平台或有人站出来进行移植之前，不会实现对 ARM 的 valgrind 支持。
另请参阅 Valgrind 团队关于移植的声明：
维护每个端口需要付出很多努力，比大多数其他程序要多。 Valgrind 是脆弱的，因为它所做的事情是低级的。此外，每个平台端口都有特定于 CPU 的代码、特定于操作系统的代码和特定于平台的代码，并且很难测试所有组合。
更新：
在 FreeBSD 上，您可以使用非常强大的 dtrace 工具进行性能监控和调试。不过，它确实有一个陡峭的学习曲线。
我最喜欢的调试工具仍然是将printf() 放在战略位置。假设您怀疑您的程序在一大段代码中崩溃。中间放一个printf，重新编译重新运行。如果您看到输出，则错误出现在 printf 之后。如果你不知道它是在printf 之前。您现在已将包含错误的块的大小减半。现在在剩余的可疑代码中间添加另一个printf 并重复。这种技术称为二分法。您还可以使用它来监控变量的值。
我建议将调试 printf 包装在一个宏中（[1]、[2]），这样您可以将它们保留在代码中，但您可以在发布构建时禁用它们。
【讨论】：
gdb 除外）有哪些选择？