Valgrind 是用于构建动态分析工具的仪器框架. 它附带了一组工具, 每个工具都执行某种调试, 分析或类似任务, 可帮助您改进程序.
Valgrind 的架构采用模块化设计, 因此可以轻松创建新工具, 而不会干扰现有结构.
开始工作前, 有两项信息不得不看, 那就是平台和工具概述, 虽然百度查了一些, 但毕竟不如官方的准确:
平台支持, 我的 ARM-v7 是支持的
http://valgrind.org/info/platforms.html
工具概述:
http://valgrind.org/info/tools.html
标准配置提供了许多有用的工具.
Memcheck 是一个内存错误检测器. 它可以帮助您使程序, 尤其是那些用 C 和 C ++ 编写的程序更加正确.
Cachegrind 是缓存和分支预测分析器. 它可以帮助您使程序运行得更快.
Callgrind 是一个生成缓存分析器的调用图. 它与 Cachegrind 有一些重叠, 但也收集了 Cachegrind 没有的一些信息.
Helgrind 是一个线程错误检测器. 它可以帮助您使多线程程序更正确.
DRD 也是线程错误检测器. 它与 Helgrind 类似, 但使用不同的分析技术, 因此可能会发现不同的问题.
Massif 是一个堆分析器. 它可以帮助您使程序使用更少的内存.
DHAT 是一种不同类型的堆分析器. 它可以帮助您了解块寿命, 块利用率和布局效率低下的问题.
SGcheck 是一种实验工具, 可以检测堆栈和全局数组的溢出. 它的功能与 Memcheck 的功能互补: SGcheck 发现 Memcheck 无法解决的问题, 反之亦然.
BBV 是一个实验性的 SimPoint 基本块矢量生成器. 它对进行计算机体系结构研究和开发的人很有用.
其中官方解释到:
Memcheck 检测内存管理问题, 主要针对 C 和 C ++ 程序. Memcheck 运行程序比正常情况慢大约 10-30 倍
Cachegrind 运行程序比正常情况慢大约 20-100 倍.
Massif 运行程序比正常情况慢 20 倍
1. 下载源码
http://valgrind.org/
2 解压后进行配置:
./configure --prefix=/home/sun/share/install --host=ARM-buildroot-Linux-uclibcgnueabi
配置报错:
- checking for a supported CPU... no (ARM)
- configure: error: Unsupported host architecture. Sorry
查看官方网站首页, 发现对 ARM-Linux 是支持的
It also includes three experimental tools: a stack/global array overrun detector, a second heap profiler that examines how heap blocks are used, and a SimPoint basic block vector generator. It runs on the following platforms: X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, PPC32/Linux, PPC64/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, X86/Solaris, AMD64/Solaris, ARM/Android (2.3.x and later), ARM64/Android, X86/Android (4.0 and later), MIPS32/Android, X86/Darwin and AMD64/Darwin (Mac OS X 10.12).
修改 configure 文件:
将 armv7a* 改为 ARM* 再次配置就不会报错了
修改前:
修改后:
3. 编译
- make -j4
- make install
会生成四个目录: bin lib share include
4. 我的板子空间非常小, 所以需要删除不需要的工具, 只留下内存检查工具,
需要删除 lib/valgrind 目录下的文件 以及 整个 share 目录, 最后精简到 12M 左右:
- sun@machine:~/share/install$ du -sh bin include/ lib/
- 520K bin
- 2.1M include/
- 10M lib/
精简后的 lib/valgrind 目录下所有文件:
- 32bit-core-valgrind-s1.xml 32bit-sse.xml ARM-with-vfpv3.xml
- 32bit-core-valgrind-s2.xml ARM-core-valgrind-s1.xml default.supp
- 32bit-core.xml ARM-core-valgrind-s2.xml getoff-ARM-Linux
- 32bit-Linux-valgrind-s1.xml ARM-core.xml memcheck-ARM-Linux
- 32bit-Linux-valgrind-s2.xml ARM-vfpv3-valgrind-s1.xml vgpreload_core-ARM-Linux.so
- 32bit-Linux.xml ARM-vfpv3-valgrind-s2.xml vgpreload_memcheck-ARM-Linux.so
- 32bit-sse-valgrind-s1.xml ARM-vfpv3.xml
- 32bit-sse-valgrind-s2.xml ARM-with-vfpv3-valgrind.xml
文件名含有 ARM-Linux 字样的文件信息:
- sun@machine:~/share/install/lib/valgrind$ file *ARM-Linux*
- getoff-ARM-Linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, with debug_info, not stripped
- memcheck-ARM-Linux: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
- vgpreload_core-ARM-Linux.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, with debug_info, not stripped
- vgpreload_memcheck-ARM-Linux.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, with debug_info, not stripped
5. 对于运行环境的要求:
http://valgrind.org/docs/manual/dist.readme-packagers.html
- 7. README_PACKAGERS
- Greetings, packaging person! This information is aimed at people
- building binary distributions of Valgrind.
- Thanks for taking the time and effort to make a binary distribution of
- Valgrind. The following notes may save you some trouble.
- -- If your toolchain (compiler, linker) support lto, using the configure
- option --enable-lto=yes will produce a smaller/faster valgrind
- (up to 10%).
- -- Do not ship your Linux distro with a completely stripped
- /lib/ld.so. At least leave the debugging symbol names on -- line
- number info isn't necessary. If you don't want to leave symbols on
- ld.so, alternatively you can have your distro install ld.so's
- debuginfo package by default, or make ld.so.debuginfo be a
- requirement of your Valgrind RPM/DEB/whatever.
- Reason for this is that Valgrind's Memcheck tool needs to intercept
- calls to, and provide replacements for, some symbols in ld.so at
- startup (most importantly strlen). If it cannot do that, Memcheck
- shows a large number of false positives due to the highly optimised
- strlen (etc) routines in ld.so. This has caused some trouble in
- the past. As of version 3.3.0, on some targets (ppc32-Linux,
- ppc64-Linux), Memcheck will simply stop at startup (and print an
- error message) if such symbols are not present, because it is
- infeasible to continue.
- It's not like this is going to cost you much space. We only need
- the symbols for ld.so (a few K at most). Not the debug info and
- not any debuginfo or extra symbols for any other libraries.
- -- (Unfortunate but true) When you configure to build with the
- --prefix=/foo/bar/xyzzy option, the prefix /foo/bar/xyzzy gets
- baked into valgrind. The consequence is that you _must_ install
- valgrind at the location specified in the prefix. If you don't,
- it may appear to work, but will break doing some obscure things,
- particularly doing fork() and exec().
- So you can't build a relocatable RPM / whatever from Valgrind.
- -- Don't strip the debug info off lib/valgrind/$platform/vgpreload*.so
- in the installation tree. Either Valgrind won't work at all, or it
- will still work if you do, but will generate Less helpful error
- messages. Here's an example:
- Mismatched free() / delete / delete []
- at 0x40043249: free (vg_clientfuncs.c:171)
- by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
- by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
- by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
- Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd
- at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152)
- by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
- by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
- by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
- This tells you that some memory allocated with new[] was freed with
- free().
- Mismatched free() / delete / delete []
- at 0x40043249: (inside vgpreload_memcheck.so)
- by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
- by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
- by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
- Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd
- at 0x4004318C: (inside vgpreload_memcheck.so)
- by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
- by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
- by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
- This isn't so helpful. Although you can tell there is a mismatch,
- the names of the allocating and deallocating functions are no longer
- visible. The same kind of thing occurs in various other messages
- from valgrind.
- -- Don't strip symbols from lib/valgrind/* in the installation tree.
- Doing so will likely cause problems. Removing the line number info is
- probably OK (at least for some of the files in that directory), although
- that has not been tested by the Valgrind developers.
- -- Please test the final installation works by running it on something
- huge. I suggest checking that it can start and exit successfully
- both Firefox and OpenOffice.org. I use these as test programs, and I
- know they fairly thoroughly exercise Valgrind. The command lines to use
- are:
- valgrind -v --trace-children=yes Firefox
- valgrind -v --trace-children=yes soffice
- If you find any more hints/tips for packaging, please report
- it as a bugreport. See http://www.valgrind.org for details.
- View Code
里面提到五个重要的事项:
- 如果您的工具链 (编译器, 链接器) 支持 lto, 则使用 configure 选项 --enable-lto = yes 将产生更小 / 更快的 valgrind
- 不要使用完全剥离的 Linux 发行版 / lib/ld.so.(比如上面的 getoff-ARM-Linux 就链接了 /lib/ld-uClibc.so.0, 那就要求我们的开发板根目录下的 /lib/ld-uClibc.so.0 必须是 not stripped)
在开发板上面运行的目录必须与 --prefix = 指定的目录完全一致
- 不要将调试信息从 lib / valgrind / $ platform / vgpreload * .so 中删除(比如上面的 vgpreload_core-ARM-Linux.so 和 vgpreload_memcheck-ARM-Linux.so 必须是 not stripped)
- 不要在安装树中从 lib / valgrind /* 中删除符号.(比如上面的 getoff-ARM-Linux 和 memcheck-ARM-Linux 必须是 not stripped)
第 4,5 两条就要求我们 lib/valgrind/ 目录下的任何文件都必须是 not stripped, 这样才能保证程序可靠
将所有精简后的目录放到开发板的指定目录(即 --prefix=/home/sun/share/install 这个目录), 如果你忘记了当时编译的目录是哪个, 请查看 lib/pkgconfig/valgrind.pc
文件内有绝对路径的说明: 如 prefix=/home/sun/share/install
- sun@machine:~/share/install/lib/pkgconfig$ cat valgrind.pc
- prefix=/home/sun/share/install
- exec_prefix=${
- prefix
- }
- libdir=${
- exec_prefix
- }/lib
- includedir=${
- prefix
- }/include/valgrind
- arch=ARM
- os=Linux
- platform=ARM-Linux
- valt_load_address=0x58000000
- Name: Valgrind
- Description: A dynamic binary instrumentation framework
- Version: 3.14.0
- Requires:
- Libs: -L${
- libdir
- }/valgrind -lcoregrind-ARM-Linux -lvex-ARM-Linux -lgcc
- Cflags: -I${
- includedir
- }
一般情况下都可以成功运行, 偶尔 adb push 进去后不能运行, 如果已经确定在开发板上面的路径与 prefix 指定的路径完全一致了, 但依然报以下错误:
valgrind: failed to start tool 'memcheck' for platform 'arm-linux': No such file or directory
那就需要指定库的路径了:
VALGRIND_LIB=/home/sun/share/install/lib ./valgrind/home/sun/share/install/bin/valgrind --help
如果可以正常运行, 那就设置到环境变量, 只在当前终端有效, 如果开启另一个终端, 则需要再次设置, 如果终端关闭或板子重启, 同样需要再次设置:
export VALGRIND_LIB=/home/test/valgrind/lib/valgrind
设置后就可以直接运行了 ./valgrind/home/sun/share/install/bin/valgrind --help 可以成功运行
./valgrind/home/sun/share/install/bin/valgrind ls 报错
错误信息是: 内部错误, valgrind 段错误退出了
来来回回折腾了好几天, 交叉工具链都重新制作了, 用新版本的 uclibc, 依然报错
替换内核版本后 依然报错
换成几个旧版本的 valgrind 依然报错
最后又重新查看 valgrind 对平台的 CPU 架构的支持, 才发现一开始就由于疏忽错过了重要信息
当前
Valgrind 支持以下平台:
x86 / Linux: 最高可包括 SSSE3, 但不高 - 没有 SSE4,AVX,AVX2. 此目标现在处于维护模式..
AMD64 / Linux: 包括 AVX2 在内. 这是主要的开发目标, 并且往往得到很好的支持.
PPC32 / Linux,PPC64 / Linux,PPC64LE / Linux: 包括 Power8 在内.
S390X / Linux: 支持.
ARM / Linux: 自 ARMv7 起支持.
ARM64 / Linux: ARMv8 支持.
MIPS32 / Linux,MIPS64 / Linux: 支持.
X86 / Solaris,AMD64 / Solaris,X86 / illumos,AMD64 / illumos : 自 Solaris 11 以来受支持.
X86 / Darwin(10.10,10.11),AMD64 / Darwin(10.10,10.11): 支持.
ARM / Android,ARM64 / Android,MIPS32 / Android,X86 / Android: 支持.
在 Linux 上, 您必须运行内核 3.0 或更高版本, 以及 glibc 2.5.X 或更高版本. 在 Mac OS X 上, 您必须运行 10.9.x 或更高版本.
移植计划
Valgrind 3.X 拥有支持多平台的基础设施. 平台是特定的 (CPU,OS) 配对, 例如 x86 / Linux 或 AMD64 / Linux.
维护每个端口需要付出很多努力, 比大多数其他程序要多. Valgrind 很脆弱, 因为它的作用很低级. 此外, 每个平台端口都有特定于 CPU 的代码, 特定于操作系统的代码和特定于平台的代码, 并且难以测试所有组合.
因此, 我们只能证明支持广泛使用的平台. 与 NetBSD 或 GCC 不同, 我们对 Valgrind 在已知领域的每个平台上工作都不感兴趣: 维护负担过高. 因此, 将 Valgrind 移植到不同的平台并不仅仅是一项技术练习: 您还需要做出一个令人信服的案例, 即努力是值得的, 并且至少在可预见的未来, 端口将得到适当的支持.
Windows 不在考虑之中, 因为移植到它需要进行如此多的更改, 它几乎就是一个单独的项目. (但是, Valgrind + Wine 可以通过一些努力来实现.)此外, 非开源操作系统很难处理; 能够看到操作系统和相关的 (libc) 源代码使事情变得更容易. 但是, Valgrind 可以与 Wine 结合使用, 这意味着可以在 Valgrind 下运行 Windows 程序.
此消息说明了我们的移植原理. 我们一如既往地采用灵活的方法, 如果您有任何意见, 我们有兴趣听取您的意见 / 移植需求.
我的内核是 4.4.110 支持的, 但 C 库是 uclibc valgrind 不支持, 所以无法运行
最后, valgrind 在 ARM Linux 下交叉编译时:
对 CPU 架构, 内核版本, Glibc 版本都有严格要求, 大家在移植前需要到官网查看
来源: https://www.cnblogs.com/CodingTheFuture/p/9864960.html