valgrind arm-linux 交叉編譯

Valgrind是用於構建動態分析工具的儀器框架。 它附帶了一組工具，每個工具都執行某種調試，分析或類似任務，可幫助您改進程序。

Valgrind的架構采用模塊化設計，因此可以輕松創建新工具，而不會干擾現有結構。

 

開始工作前，有兩項信息不得不看，那就是平台和工具概述，雖然百度查了一些，但畢竟不如官方的准確：

平台支持，我的 ARM-v7 是支持的

http://valgrind.org/info/platforms.html

工具概述：

http://valgrind.org/info/tools.html

 

標准配置提供了許多有用的工具。

1. Memcheck是一個內存錯誤檢測器。 它可以幫助您使程序，尤其是那些用C和C ++編寫的程序更加正確。

2. Cachegrind是緩存和分支預測分析器。 它可以幫助您使程序運行得更快。

3. Callgrind是一個生成緩存分析器的調用圖。 它與Cachegrind有一些重疊，但也收集了Cachegrind沒有的一些信息。

4. Helgrind是一個線程錯誤檢測器。 它可以幫助您使多線程程序更正確。

5. DRD也是線程錯誤檢測器。 它與Helgrind類似，但使用不同的分析技術，因此可能會發現不同的問題。

6. Massif是一個堆分析器。 它可以幫助您使程序使用更少的內存。

7. DHAT是一種不同類型的堆分析器。 它可以幫助您了解塊壽命，塊利用率和布局效率低下的問題。

8. SGcheck是一種實驗工具，可以檢測堆棧和全局數組的溢出。 它的功能與Memcheck的功能互補：SGcheck發現Memcheck無法解決的問題，反之亦然。

9. 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.

里面提到五個重要的事項：

1 - 如果您的工具鏈（編譯器，鏈接器）支持lto，則使用configure 選項--enable-lto = yes將產生更小/更快的valgrind

2 - 不要使用完全剝離的Linux發行版/lib/ld.so。（比如上面的getoff-arm-linux 就鏈接了 /lib/ld-uClibc.so.0， 那就要求我們的開發板根目錄下的 /lib/ld-uClibc.so.0 必須是 not stripped） 3 在開發板上面運行的目錄必須與 --prefix = 指定的目錄完全一致
 
4 - 不要將調試信息從lib / valgrind / $ platform / vgpreload * .so中刪除（比如上面的vgpreload_core-arm-linux.so 和 vgpreload_memcheck-arm-linux.so 必須是 not stripped） 5 - 不要在安裝樹中從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 版本都有嚴格要求，大家在移植前需要到官網查看