運(yùn)行Valgrind工具toolname，例如memcheck，cachegrind，callgrind，helgrind，drd，massif，lackey，none，exp-sgcheck，exp-bbv，exp-dhat等

顯示所有選項(xiàng)的幫助，包括核心和所選工具。如果該選項(xiàng)重復(fù)，則相當(dāng)于給予?--help-debug。

--help與之一樣，但也列出了通常僅用于Valgrind開發(fā)人員的調(diào)試選項(xiàng)。

顯示Valgrind內(nèi)核的版本號。工具可以有自己的版本號。有一個方案來確保只有核心版本是已知的工具才能執(zhí)行的工具。這樣做是為了盡量減少由于工具與核心版本不兼容而產(chǎn)生的奇怪問題的機(jī)會。

靜默運(yùn)行，只打印錯誤消息。如果您正在進(jìn)行回歸測試或有其他自動化測試機(jī)器，那么有用。

更冗長?提供有關(guān)程序各個方面的更多信息，例如：加載的共享對象，使用的禁用，檢測和執(zhí)行引擎的進(jìn)度以及有關(guān)異常行為的警告。重復(fù)該選項(xiàng)會增加詳細(xì)程度。

啟用后，Valgrind將跟蹤通過exec系統(tǒng)調(diào)用發(fā)起的子進(jìn)程。這對于多進(jìn)程程序是必需的。

請注意，Valgrind確實(shí)會追蹤到一個fork（的孩子）?，因?yàn)?fork這樣一個進(jìn)程的相同拷貝就很難，所以這個選項(xiàng)可能被命名得很糟。然而，大多數(shù)fork電話的孩子?立即打電話exec?。

此選項(xiàng)僅在指定時--trace-children=yes才有效果?。它允許一些孩子被跳過。該選項(xiàng)為Valgrind不應(yīng)該跟蹤的可執(zhí)行文件的名稱使用逗號分隔的模式列表。這些模式可以包括元字符??和*，它們具有通常的意義。

這可以用于從Valgrind上運(yùn)行的進(jìn)程樹中修剪不感興趣的分支。但是，使用它時應(yīng)該小心。當(dāng)Valgrind跳過跟蹤到可執(zhí)行文件時，它不會跳過跟蹤該可執(zhí)行文件，它也跳過跟蹤任何可執(zhí)行文件的子進(jìn)程。換句話說，該標(biāo)志不僅僅是引起跟蹤停止在指定的可執(zhí)行文件 - 它跳過跟蹤任何一個指定的可執(zhí)行文件的整個進(jìn)程子樹。

這是一樣的?--trace-children-skip，有一個區(qū)別：關(guān)于是否追蹤到子進(jìn)程的決定是通過檢查子進(jìn)程的參數(shù)而不是其可執(zhí)行文件的名稱來進(jìn)行的。

啟用后，Valgrind不會顯示任何來自fork調(diào)用的子進(jìn)程的調(diào)試或記錄輸出。這可以使輸出在處理創(chuàng)建子進(jìn)程時更不容易混淆（盡管更具誤導(dǎo)性）。它特別有用--trace-children=。如果要求XML輸出（--xml=yes），則強(qiáng)烈建議使用此選項(xiàng)，否則來自子級和父級的XML可能會混淆，這通常會使其無用。

當(dāng)Valgrind的將提供“gdbserver的”功能?--vgdb=yes或--vgdb=full指定的。這允許外部GNU GDB調(diào)試器在Valgrind上運(yùn)行時控制和調(diào)試程序。?--vgdb=full引起顯著的性能開銷，但提供更精確的斷點(diǎn)和觀察點(diǎn)。有關(guān)詳細(xì)說明，請參閱使用Valgrind的gdbserver和GDB調(diào)試程序。

如果嵌入式gdbserver已啟用但目前沒有使用gdb，則vgdb?命令行實(shí)用程序可以從shell向Valgrind發(fā)送“監(jiān)視器命令”。Valgrind內(nèi)核提供一組?Valgrind監(jiān)視器命令。工具可以選擇提供特定于工具的監(jiān)視器命令，這些命令在工具特定的章節(jié)中有所記錄。

當(dāng)Valgrind gdbserver啟用--vgdb=yes或時，使用此選項(xiàng)?--vgdb=full。報告錯誤的工具將number在凍結(jié)程序并等待您與GDB連接之前等待“?”錯誤報告。因此，值為零將導(dǎo)致在執(zhí)行程序之前啟動gdbserver。這通常用于在執(zhí)行前插入GDB斷點(diǎn)，并且還可以與不報告錯誤的工具（如Massif）一起使用。

當(dāng)Valgrind gdbserver啟用--vgdb=yes或時，使用此選項(xiàng)?--vgdb=full。--vgdb-error報告之后，將為每個錯誤調(diào)用Valgrind gdbserver?。您還可以詢問為其他事件調(diào)用Valgrind gdbserver，以下列方式之一指定：

• 一個或多個逗號分隔的列表?startup exit valgrindabexit。

  值startup?exit?valgrindabexit分別表示在程序執(zhí)行之前，在程序的最后一個指令之后，在Valgrind異常退出（例如內(nèi)部錯誤，內(nèi)存不足，...）中調(diào)用gdbserver。

  注意：startup并且?--vgdb-error=0將會在程序執(zhí)行之前調(diào)用Valgrind gdbserver。此外?--vgdb-error=0，還將導(dǎo)致您的程序停止所有后續(xù)錯誤。

• all指定完整集。相當(dāng)于?--vgdb-stop-at=startup,exit,valgrindabexit。

• none?為空集。

啟用后，Valgrind將通過gdbserver monitor命令在出口或請求時打印出打開的文件描述符列表v.info open_fds。與每個文件描述符一起打印文件打開位置的堆棧回溯以及與文件描述符相關(guān)的任何細(xì)節(jié)，如文件名或套接字詳細(xì)信息。

啟用后，每個消息之前都會顯示自啟動以來的已經(jīng)逝去的時鐘，表示為天，小時，分鐘，秒和毫秒。

指定Valgrind應(yīng)將其所有消息發(fā)送到指定的文件描述符。默認(rèn)值2是標(biāo)準(zhǔn)錯誤通道（stderr）。請注意，這可能會干擾客戶端自己使用stderr，因?yàn)閂algrind的輸出將與客戶端發(fā)送給stderr的任何輸出交錯。

指定Valgrind應(yīng)將其所有郵件發(fā)送到指定的文件。如果文件名為空，則會導(dǎo)致中止。有三種特殊的格式說明符可以在文件名中使用。

%p被當(dāng)前進(jìn)程ID替換。這對于調(diào)用多個進(jìn)程的程序非常有用。警告：如果您使用--trace-children=yes并且您的程序調(diào)用多個進(jìn)程或您的程序fork而不調(diào)用exec，并且您不使用此說明符（或%q下面的說明符），則所有這些進(jìn)程的Valgrind輸出將進(jìn)入一個文件，可能會混亂并且可能不完整。

%q{FOO}被替換為環(huán)境變量的內(nèi)容FOO。如果?{FOO}部件畸形，會導(dǎo)致中止。此說明符很少需要，但在某些情況下（例如運(yùn)行MPI程序時）非常有用。這個想法是指定一個變量，該變量將為作業(yè)中的每個進(jìn)程設(shè)置不同，例如BPROC_RANK或MPI設(shè)置中適用的任何內(nèi)容。如果未設(shè)置命名環(huán)境變量，則會導(dǎo)致中止。請注意，在某些shell中，?角色{和}角色可能需要使用反斜杠進(jìn)行轉(zhuǎn)義。

%%被替換%。

如果%其后的任何其他字符，則導(dǎo)致中止。

如果文件名指定相對文件名，則將其放入程序的初始工作目錄中：當(dāng)程序在fork之后或exec之后執(zhí)行時，這是當(dāng)前目錄。如果它指定絕對文件名（即以'/'開始），那么它將放在那里。

指定Valgrind應(yīng)將其所有消息發(fā)送到指定IP地址的指定端口。可以省略端口，在這種情況下使用端口1500。如果無法連接到指定的套接字，則Valgrind將返回寫入標(biāo)準(zhǔn)錯誤（stderr）的輸出。此選項(xiàng)旨在與valgrind-listener程序一起使用?。有關(guān)詳細(xì)信息，請參閱?手冊中的注釋。

啟用時，輸出的重要部分（例如工具錯誤消息）將采用XML格式而不是純文本格式。此外，XML輸出將被發(fā)送到與純文本輸出不同的輸出通道。因此，還必須使用的一個?--xml-fd，--xml-file或?--xml-socket到指定的XML將被發(fā)送。

不太重要的消息將仍然以純文本被打印，但是，因?yàn)閄ML輸出和明文輸出被發(fā)送到不同的輸出信道（純文本輸出的目的地仍然由控制--log-fd，--log-file?和--log-socket）這不應(yīng)引起問題。

此選項(xiàng)旨在使消費(fèi)Valgrind輸出的工具（如GUI前端）變得更簡單。目前這個選項(xiàng)適用于Memcheck，Helgrind，DRD和SGcheck。輸出格式在docs/internals/xml-output-protocol4.txt?Valgrind 3.5.0或更高版本的源代碼樹中的文件?中指定。

GUI請求XML輸出時，推薦的選項(xiàng)是：--xml=yes啟用XML輸出，?--xml-file將XML輸出發(fā)送到（大概是GUI選擇的）文件，--log-file將純文本輸出發(fā)送到第二個GUI選擇的文件，?--child-silent-after-fork=yes，并將?-q純文本輸出限制為由Valgrind本身創(chuàng)建的關(guān)鍵錯誤消息。例如，無法讀取指定的抑制文件將被視為關(guān)鍵錯誤消息。這樣，為了成功運(yùn)行文本輸出文件將為空。但是如果它不是空的，那么它將包含GUI用戶應(yīng)該注意的重要信息。

指定Valgrind應(yīng)將其XML輸出發(fā)送到指定的文件描述符。它必須與之配合使用?--xml=yes。

指定Valgrind應(yīng)將其XML輸出發(fā)送到指定的文件。它必須與之配合使用?--xml=yes。出現(xiàn)在文件名中的任何%p或者?%q序列以與它們完全相同的方式進(jìn)行擴(kuò)展--log-file。有關(guān)--log-file詳細(xì)信息，請參閱說明。

指定Valgrind應(yīng)將指定端口的XML輸出發(fā)送到指定的IP地址。它必須與之配合使用--xml=yes。參數(shù)的形式與使用的形式相同--log-socket。有關(guān)--log-socket?詳細(xì)信息，請參閱說明。

在XML輸出的開始處嵌入一個額外的用戶注釋字符串。僅在--xml=yes指定時才能工作;?否則忽略。

啟用/禁用C ++名稱的自動解碼（解碼）。默認(rèn)啟用。啟用后，Valgrind將嘗試將編碼的C ++名稱轉(zhuǎn)換為接近原始文件的東西。demangler處理由g ++版本2.X，3.X和4.X驅(qū)動的符號。

關(guān)于解密的一個重要事實(shí)是在壓制文件中提到的函數(shù)名稱應(yīng)該處于它們的格式。在搜索適用的抑制方面，Valgrind不會使功能名稱發(fā)生拆分，因?yàn)榉駝t會使壓縮文件內(nèi)容取決于Valgrind的分離機(jī)器的狀態(tài)，并且還會減緩抑制匹配。

指定標(biāo)識程序位置的堆棧跟蹤中顯示的最大條目數(shù)。請注意，僅使用前四個功能位置（當(dāng)前功能中的位置，以及其三個直接調(diào)用者的位置）常見錯誤。所以這并不影響所報錯誤的總數(shù)。

最大值為500.請注意，較高的設(shè)置將使Valgrind運(yùn)行速度更慢，并占用更多內(nèi)存，但在使用深嵌套的調(diào)用鏈的程序時可能會很有用。

堆棧掃描支持僅在ARM目標(biāo)上可用。

這些標(biāo)志通過堆棧掃描啟用和控制堆棧展開。當(dāng)正常堆棧展開機(jī)制 - 使用Dwarf CFI記錄和幀指針跟隨失敗時，堆棧掃描可能能夠恢復(fù)堆棧跟蹤。

請注意，堆棧掃描是一種不精確的啟發(fā)式機(jī)制，可能會產(chǎn)生非常誤導(dǎo)的結(jié)果，或者根本沒有。它只能在緊急情況下使用，正常展開失敗，重要的是仍然有堆棧跟蹤。

堆棧掃描是一種簡單的技術(shù)：展開器從堆棧中讀取單詞，并嘗試猜測哪些可能是返回地址，通過檢查它們是否指向ARM或Thumb調(diào)用指令。如果是這樣，該詞被添加到回溯。

當(dāng)函數(shù)調(diào)用返回時，會發(fā)生主要的危險，其返回地址被暴露，并且調(diào)用一個新的函數(shù)，但新函數(shù)不會覆蓋舊的地址。這樣做的結(jié)果是回溯可能包含已經(jīng)返回的函數(shù)的條目，因此非常混亂。

此實(shí)現(xiàn)的第二個限制是它將僅掃描包含起始堆棧指針的頁面（通常為4KB）。如果堆棧幀較大，則這可能導(dǎo)致軌跡中僅存在少量（甚至不甚甚）。此外，如果您不幸運(yùn)，并且在其包含頁面的末尾附近有一個初始堆棧指針，掃描可能會錯過所有有趣的幀。

默認(rèn)情況下，堆棧掃描被禁用。正常的使用情況是要求堆棧跟蹤否則會很短。所以，啟用它，使用--unw-stack-scan-thresh=number。這要求Valgrind嘗試使用堆棧掃描來“擴(kuò)展”包含少于number幀的堆棧跟蹤。

如果堆棧掃描發(fā)生，它將只生成最多指定的幀數(shù)--unw-stack-scan-frames。通常，堆棧掃描會生成這么多垃圾條目，默認(rèn)情況下該值設(shè)置為低值（5）。在任何情況下，堆棧跟蹤大于--num-callers創(chuàng)建指定的值。

啟用后，Valgrind停止報告錯誤，總共有10,000,000個，或者1,000個不同的。這是為了阻止錯誤跟蹤機(jī)制在具有許多錯誤的程序中成為巨大的性能開銷。

如果Valgrind在運(yùn)行中報告任何錯誤，則指定返回的替代退出代碼。當(dāng)設(shè)置為默認(rèn)值（零）時，Valgrind的返回值將始終是正在仿真的進(jìn)程的返回值。當(dāng)設(shè)置為非零值時，將返回該值，如果Valgrind檢測到任何錯誤。這對于使用Valgrind作為自動化測試套件的一部分非常有用，因?yàn)橥ㄟ^檢查返回碼，可以輕松檢測Valgrind報告錯誤的測試用例。

當(dāng)錯誤輸出為純文本（即XML未使用）時，?--error-markers指示在每個錯誤之前（之后）輸出包含begin（end）字符串的行。

這樣的標(biāo)記線便于搜索包含與程序輸出混合的valgrind錯誤的輸出文件中的錯誤和/或提取錯誤。

請注意，空標(biāo)記被接受。因此，只能使用開始（或結(jié)束）標(biāo)記。

啟用/禁用打印非法指令診斷。默認(rèn)情況下啟用，但默認(rèn)為禁用?--quiet。通過給出此選項(xiàng)，總是可以明確地覆蓋默認(rèn)值。

啟用該功能后，在程序發(fā)出SIGILL信號之前，每當(dāng)遇到Valgrind無法解碼或轉(zhuǎn)換的指令時，都會打印一條警告消息以及一些診斷信息。通常，非法指令表示程序中的錯誤或缺少對Valgrind特定指令的支持。但有些程序會故意嘗試執(zhí)行可能丟失的指令，并捕獲SIGILL信號以檢測處理器功能。使用此標(biāo)志可以避免在這種情況下您會得到的診斷輸出。

默認(rèn)情況下，錯誤的堆棧跟蹤不會顯示下面的任何函數(shù)，main因?yàn)榇蠖鄶?shù)時候它不感興趣C庫東西和/或gobbledygook。或者，如果main堆棧跟蹤中不存在堆棧跟蹤，堆棧跟蹤將不會顯示main類似函數(shù)（如glibc）的?任何函數(shù)__libc_start_main。此外，如果?main跟蹤中存在類似函數(shù)，則它們被歸一化為(below main)使得輸出更確定。

如果啟用此選項(xiàng)，將顯示所有堆棧跟蹤條目，并且main類似的函數(shù)將不會被歸一化。

默認(rèn)情況下，Valgrind僅顯示堆棧跟蹤中的文件名，但不顯示源文件的完整路徑。當(dāng)在大型項(xiàng)目中使用Valgrind，其中源位于多個不同的目錄中時，這可能是不方便的。?--fullpath-after為這個問題提供了靈活的解決方案。當(dāng)此選項(xiàng)存在時，將顯示每個源文件的路徑，其中包含以下所有重要的注意事項(xiàng)：如果string在路徑中找到，則將string省略直到和包含的路徑，否則路徑未修改。注意，string不需要作為路徑的前綴。

例如，考慮一個名為的文件?/home/janedoe/blah/src/foo/bar/xyzzy.c。指定--fullpath-after=/home/janedoe/blah/src/?將導(dǎo)致Valgrind顯示名稱foo/bar/xyzzy.c。

因?yàn)樽址恍枰鳛榍熬Y，所以?--fullpath-after=src/會產(chǎn)生相同的輸出。當(dāng)路徑包含任意機(jī)器生成的字符時，這很有用。例如，/my/build/dir/C32A1B47/blah/src/foo/xyzzy?可以修剪路徑?以foo/xyzzy?使用?--fullpath-after=/blah/src/。

如果您只想看到完整的路徑，只需指定一個空字符串：--fullpath-after=。這不是一個特殊情況，只是上述規(guī)則的邏輯后果。

最后，你可以--fullpath-after?多次使用。任何外觀都會導(dǎo)致Valgrind切換到生成完整路徑并應(yīng)用上述過濾規(guī)則。每個生成的路徑按照--fullpath-after指定的順序與所有指定的字符串進(jìn)行比較。要匹配的第一個字符串將導(dǎo)致路徑被截斷，如上所述。如果不匹配，則顯示完整路徑。當(dāng)源從多個不相關(guān)的目錄中抽取時，這有助于切除前綴。

默認(rèn)情況下，Valgrind在幾個眾所周知的路徑中搜索調(diào)試對象，例如/usr/lib/debug/。

但是，您可能希望將調(diào)試對象放置在任意位置，例如在具有有限本地存儲空間的移動設(shè)備上運(yùn)行Valgrind時的外部存儲。另一個例子可能是您沒有在運(yùn)行Valgrind的系統(tǒng)上安裝調(diào)試對象包的權(quán)限的情況。

在這些情況下，您可以提供絕對路徑作為Valgrind通過指定搜索調(diào)試對象的額外最終位置?--extra-debuginfo-path=/path/to/debug/objects。給定的路徑將被添加到搜索對象的絕對路徑名稱。例如，如果Valgrind正在尋找/w/x/y/zz.so?和--extra-debuginfo-path=/a/b/c指定的debuginfo，那么它將在此處查找一個調(diào)試對象?/a/b/c/w/x/y/zz.so。

該標(biāo)志只能指定一次。如果指定多次，則只會保留最后一個實(shí)例。

這是在3.9.0版本中引入的一個新的，實(shí)驗(yàn)性的功能。

在某些情況下，從存儲在不同機(jī)器上的對象讀取debuginfo可能很方便。使用此標(biāo)志，Valgrind將在本地文件系統(tǒng)中找不到debuginfo對象時查詢運(yùn)行在ipaddr偵聽端口上的debuginfo服務(wù)器port。

debuginfo服務(wù)器必須接受端口上的TCP連接port。debuginfo服務(wù)器包含在源文件中auxprogs/valgrind-di-server.c。它將僅從它啟動的目錄中提供。?port如果未指定，默認(rèn)為客戶端和服務(wù)器的1500。

如果Valgrind?/w/x/y/zz.so通過使用debuginfo服務(wù)器查找debuginfo，它將剝離路徑名組件，并僅zz.so在服務(wù)器上請求。反過來，它將僅在其當(dāng)前工作目錄中查找匹配的debuginfo對象。

根據(jù)Valgrind的要求，debuginfo數(shù)據(jù)以小片段（8 KB）傳輸。使用LZO壓縮每個塊以減少傳輸時間。通過單階段802.11g（WiFi）網(wǎng)絡(luò)鏈路實(shí)現(xiàn)了最佳性能。

請注意，即使使用debuginfo服務(wù)器，也會執(zhí)行使用GNU debuglink CRC方案來匹配主要和調(diào)試對象的檢查。要禁用此類檢查，您還需要指定?--allow-mismatched-debuginfo=yes。

默認(rèn)情況下，Valgrind構(gòu)建系統(tǒng)將為valgrind-di-server目標(biāo)平臺構(gòu)建，這幾乎肯定不是您想要的。到目前為止，我們一直無法找到如何獲取automake / autoconf來構(gòu)建它的構(gòu)建平臺。如果要使用它，則必須使用頂部顯示的命令手動重新編譯它auxprogs/valgrind-di-server.c。

當(dāng)從單獨(dú)的debuginfo對象讀取debuginfo時，Valgrind將默認(rèn)使用GNU debuglink機(jī)制檢查main和debuginfo對象是否匹配。這樣保證它不會從過期的debuginfo對象中讀取debuginfo，并且還可以確保Valgrind不會因?yàn)椴黄ヅ涠罎ⅰ?/p>

此檢查可以使用?--allow-mismatched-debuginfo=yes。當(dāng)debuginfo和主對象沒有以正確的方式拆分時，這可能很有用。盡管如此，使用它時要小心：它禁用所有一致性檢查，并且當(dāng)主要和debuginfo對象不匹配時，Valgrind被觀察到崩潰。

指定一個額外的文件，從中讀取要抑制的錯誤的描述。您可以使用多達(dá)100個額外的壓縮文件。

設(shè)置后yes，Valgrind將在每次顯示錯誤后暫停，并打印行：

????----?Print?suppression???---?[Return/N/n/Y/y/C/c]?----

按Ret或，N Ret或?n Ret導(dǎo)致Valgrind繼續(xù)執(zhí)行而不打印此錯誤的抑制。

按下Y Ret或?y Ret導(dǎo)致Valgrind寫入此錯誤的抑制。如果您不想再聽到有關(guān)該錯誤的信息，可以將其剪切并粘貼到抑制文件中。

設(shè)置時all，Valgrind將會針對每個報告的錯誤打印一個抑制，而不會查詢用戶。

此選項(xiàng)對于C ++程序特別有用，因?yàn)樗鶕?jù)需要打印出具有破壞名稱的抑制。

請注意，打印的壓印盡可能具體。您可能希望通過添加通配符到函數(shù)名稱以及使用幀級別的通配符來尋找類似的通配符。通配設(shè)備功能強(qiáng)大而靈活，并且經(jīng)過仔細(xì)的編輯，您可能只需少量的壓制即可抑制整個系列的相關(guān)錯誤。

有時兩個不同的錯誤被同樣的抑制所壓制，在這種情況下，Valgrind將會多次輸出抑制，但您只需要在壓縮文件中有一個副本（但是不止一個則不會導(dǎo)致問題）。此外，抑制名稱為?<insert a suppression name here>：該名稱并不重要，它只用于-v打印所有使用的抑制記錄的選項(xiàng)。

當(dāng)使用?--gen-suppressions=yes時，Valgrind將停止，以便在發(fā)生每個錯誤時讀取您的鍵盤輸入。默認(rèn)情況下，它從標(biāo)準(zhǔn)輸入（stdin）讀取，這對于關(guān)閉stdin的程序是有問題的。此選項(xiàng)允許您指定從中讀取輸入的備用文件描述符。

此選項(xiàng)僅在Mac OS X上運(yùn)行Valgrind時才有用。

Mac OS X使用延遲調(diào)試信息（debuginfo）鏈接方案。當(dāng)包含debuginfo的對象文件鏈接到一個.dylib或可執(zhí)行文件中時，debuginfo不會被復(fù)制到最終文件中。相反，必須通過在可執(zhí)行文件上運(yùn)行dsymutil系統(tǒng)提供的實(shí)用程序來手動鏈接debuginfo?.dylib。生成的組合debuginfo放在可執(zhí)行文件旁邊的目錄中，或者.dylib擴(kuò)展名.dSYM。

使用--dsymutil=no，Valgrind將檢測?.dSYM目錄丟失或存在的情況，但不符合關(guān)聯(lián)的可執(zhí)行文件，或者.dylib很可能是因?yàn)樗堰^期。在這種情況下，Valgrind會打印一個警告消息，但不采取進(jìn)一步行動。

隨著--dsymutil=yes，Valgrind的意志，在這樣的情況下，自動運(yùn)行dsymutil必要使debuginfo軟最新的。對于所有實(shí)際的目的，如果您始終使用--dsymutil=yes，則絕對不需要dsymutil手動運(yùn)行或作為應(yīng)用程序構(gòu)建系統(tǒng)的一部分運(yùn)行，因?yàn)閂algrind將根據(jù)需要運(yùn)行它。

Valgrind的不會嘗試運(yùn)行dsymutil在任何可執(zhí)行文件或庫?/usr/，?/bin/，?/sbin/，?/opt/，?/sw/，?/System/，?/Library/或?/Applications/?因?yàn)閐symutil總是會在這種情況下失敗。它失敗了，因?yàn)檫@種預(yù)安裝的系統(tǒng)組件的debuginfo在任何地方都不可用，也因?yàn)樗枰@些目錄中的寫入權(quán)限。

使用--dsymutil=yes時要小心，因?yàn)樗鼤?dǎo)致預(yù)先存在的.dSYM?目錄被靜默刪除并重新創(chuàng)建。還要注意的?dsymutil是相當(dāng)慢，有的時候太過分了。

堆棧幀的最大大小。如果堆棧指針移動超過此值，則Valgrind將假定程序正在切換到另一個堆棧。

如果您的程序具有大量堆棧分配的數(shù)組，則可能需要使用此選項(xiàng)。Valgrind跟蹤程序的堆棧指針。如果它改變超過閾值，Valgrind假設(shè)您的程序正在切換到不同的堆棧，Memcheck的行為與堆棧指針變化小于閾值的行為不同。通常這個啟發(fā)式工作原理很好。但是，如果您的程序在堆棧中分配大型結(jié)構(gòu)，則該啟發(fā)式將被愚弄，并且Memcheck將會報告大量的無效堆棧訪問。此選項(xiàng)允許您將閾值更改為不同的值。

如果Valgrind的調(diào)試輸出指示您這樣做，您應(yīng)該僅考慮使用此選項(xiàng)。在這種情況下，它會告訴您應(yīng)該指定的新閾值。

通常，在堆棧上分配大型結(jié)構(gòu)是一個壞主意，因?yàn)槟梢暂p松地耗盡堆棧空間，特別是在內(nèi)存有限的系統(tǒng)上，或者希望支持大量線程，每個都有一個小堆棧，并且還因?yàn)殄e誤由Memcheck執(zhí)行的檢查對堆分配數(shù)據(jù)比對堆棧分配的數(shù)據(jù)更有效。如果您必須使用此選項(xiàng)，您可能希望考慮將代碼重寫為在堆上分配而不是堆棧。

指定主線程堆棧的大小。

為了簡化內(nèi)存管理，Valgrind在啟動時保留主線程堆棧的所有空間。這意味著它需要在啟動時知道所需的堆棧大小。

默認(rèn)情況下，Valgrind使用當(dāng)前的“ulimit”值作為堆棧大小，或16 MB，以較低者為準(zhǔn)。在許多情況下，這將提供8到16 MB的堆棧大小，對于大多數(shù)應(yīng)用程序幾乎不會溢出。

如果您需要更大的總堆棧大小，請使用--main-stacksize它來指定它。只需將其設(shè)置為您所需的高度，因?yàn)楸Ａ舯饶枰母嗫臻g（即，比您需要的數(shù)百兆字節(jié)）約束了Valgrind的內(nèi)存分配器，并可能減少Valgrind可以使用的內(nèi)存總量。這對32位機(jī)器來說真的很重要。

在Linux上，您可以要求一個大小為2GB的堆棧。如果無法分配堆棧，Valgrind將會停止診斷消息。

--main-stacksize只影響程序初始線程的堆棧大小。它對線程棧的大小沒有任何影響，因?yàn)閂algrind不會分配它們。

您可能需要同時使用--main-stacksize?和--max-stackframe在一起。重要的是要理解，--main-stacksize設(shè)置最大堆棧總數(shù)，同時--max-stackframe指定任何一個堆棧幀的最大大小。您將必須--main-stacksize為自己找出價值（通常，如果您的應(yīng)用程序發(fā)生故障）。但是--max-stackframe，如果需要，Valgrind會告訴你需要的尺寸。

如在描述中進(jìn)一步討論的--max-stackframe，對于大堆棧的要求是潛在可移植性問題的跡象。最好建議將所有大數(shù)據(jù)放在堆分配的內(nèi)存中。

默認(rèn)情況下，Valgrind最多可處理500個線程。偶爾，這個數(shù)字太小了。使用此選項(xiàng)提供不同的限制。例如?--max-threads=3000。

默認(rèn)情況下Valgrind的的malloc，?realloc等等，返回塊，其起始地址為8字節(jié)對齊或16字節(jié)對齊（數(shù)值取決于平臺和相匹配的平臺默認(rèn)）。此選項(xiàng)允許您指定不同的對齊方式。提供的值必須大于或等于默認(rèn)值小于或等于4096，并且必須是2的冪。

Valgrind的malloc, realloc,等等，在運(yùn)行程序分配的每個堆塊之前和之后添加填充塊。這種填充塊稱為redzones。redzone大小的默認(rèn)值取決于工具。例如，Memcheck在客戶端分配的每個塊之前和之后增加并保護(hù)至少16個字節(jié)。這允許它檢測最多16個字節(jié)的塊欠載或超限。

增加紅色區(qū)域大小可以檢測更大距離的超限，但會增加Valgrind使用的內(nèi)存量。減少紅區(qū)大小將減少Valgrind所需的內(nèi)存，同時也降低了檢測超出/欠載的機(jī)會，因此不推薦使用。

此選項(xiàng)控制Valgrind對自修改代碼的檢測。如果沒有進(jìn)行任何檢查，當(dāng)程序執(zhí)行一些代碼時，用新的代碼覆蓋它，并執(zhí)行新的代碼，Valgrind將繼續(xù)執(zhí)行舊代碼的翻譯。這可能會導(dǎo)致錯誤的行為和/或崩潰。

對于“現(xiàn)代”架構(gòu) - 任何不是x86，amd64或s390x - 的默認(rèn)設(shè)置stack。這是因?yàn)檎_的程序必須采取明確的行動來重新建立代碼修改后的DI緩存一致性。Valgrind遵守并尊重此類行為，結(jié)果是自我修改代碼以零額外成本進(jìn)行透明處理。

對于x86，amd64和s390x，程序不需要通知硬件所需的DI一致性同步。因此，默認(rèn)是all-non-file覆蓋將代碼生成到匿名（非文件備份）mmap'd區(qū)域的正常情況。

四種可用設(shè)置的含義如下。無檢測（none）檢測堆棧上的自修改代碼（由GCC用于實(shí)現(xiàn)嵌套函數(shù)）（stack），檢測每個地方的自修改代碼all，并檢測除了文件支持的映射之外的其他修改代碼（all-non-file）。

跑步all會緩慢的下降。運(yùn)行時none很少加快速度，因?yàn)楹苌俚拇a在大多數(shù)程序中動態(tài)生成。該?VALGRIND_DISCARD_TRANSLATIONS客戶端請求是一種替代--smc-check=all?和--smc-check=all-non-file?需要更多的程序員的努力，但允許Valgrind的更快地運(yùn)行您的程序，告訴它準(zhǔn)確翻譯時需要重新制作。

--smc-check=all-non-file提供了更便宜但更有限的版本--smc-check=all。它會將檢查添加到不是源于文件支持的內(nèi)存映射的任何翻譯。生成代碼的典型應(yīng)用程序（例如Web瀏覽器中的JIT）將生成代碼到匿名的mmaped區(qū)域，而瀏覽器的“固定”代碼總是存在于文件支持的映射中。?--smc-check=all-non-file?利用這一觀察，限制檢查可能是JIT生成的代碼的開銷。

啟用后，Valgrind將從DWARF3調(diào)試信息中讀取有關(guān)內(nèi)聯(lián)函數(shù)調(diào)用的信息。這減慢了Valgrind啟動并使其使用更多的內(nèi)存（通常為每個內(nèi)聯(lián)代碼段，6個字和空格用于函數(shù)名稱），但它會導(dǎo)致更多描述性的堆棧跟蹤。對于3.10.0版本，默認(rèn)情況下僅對Linux，Android和Solaris目標(biāo)以及僅用于Memcheck，Helgrind和DRD的工具啟用此功能。以下是一些堆棧跟蹤的示例?--read-inline-info=no：

以下是與以下相同的錯誤?--read-inline-info=yes：

啟用后，Valgrind將從DWARF3調(diào)試信息中讀取有關(guān)變量類型和位置的信息。這顯著減緩了Valgrind的啟動，并使其占用了更多的內(nèi)存，但是對于可以利用它的工具（Memcheck，Helgrind，DRD），它可能會導(dǎo)致更精確的錯誤消息。例如，以下是Memcheck發(fā)出的一些標(biāo)準(zhǔn)錯誤：

以下是與以下相同的錯誤?--read-var-info=yes：

作為其主循環(huán)的一部分，Valgrind調(diào)度程序?qū)⑤喸円詸z查某些活動（例如外部命令或gdb的某些輸入）是否必須由gdbserver處理。在運(yùn)行給定數(shù)量的基本塊（或略大于給定數(shù)量的基本塊）之后，將進(jìn)行此活動輪詢。這個投票相當(dāng)便宜，所以默認(rèn)值設(shè)置得比較低。如果vgdb無法使用ptrace系統(tǒng)調(diào)用中斷Valgrind，如果系統(tǒng)調(diào)用中的所有線程（大部分時間）被阻止，您可能會進(jìn)一步減少此值。

激活時，gdbserver會將Valgrind影子寄存器公開到GDB。這樣，可以使用GDB檢查或更改Valgrind影子寄存器的值。隱藏影子寄存器僅適用于GDB 7.1或更高版本。

要與gdb / vgdb通信，Valgrind gdbserver會創(chuàng)建3個文件（2個命名的FIFO和一個mmap共享內(nèi)存文件）。prefix選項(xiàng)控制創(chuàng)建這些文件的目錄和前綴。

此選項(xiàng)僅在Linux上運(yùn)行Valgrind時才有用。

libc.so所有程序使用的GNU C庫（）可能會為自己的用途分配內(nèi)存。通常，當(dāng)程序結(jié)束時，它不會釋放內(nèi)存，因?yàn)長inux內(nèi)核在進(jìn)程退出時會回收所有進(jìn)程資源，所以它只會減慢速度。

glibc作者意識到，當(dāng)出口檢查完成時，這種行為會導(dǎo)致漏洞檢查器（如Valgrind）錯誤地報告glibc中的泄漏。為了避免這種情況，他們提供了一個__libc_freeres?專門用于使glibc釋放其分配的所有內(nèi)存的例程。因此，Memcheck嘗試__libc_freeres在退出時運(yùn)行?。

不幸的是，在一些很舊的glibc版本中，?__libc_freeres足夠錯誤的引起分段錯誤。這在Red Hat 7.1中尤其明顯。所以這個選項(xiàng)是為了禁止運(yùn)行而提供的?__libc_freeres。如果您的程序似乎在Valgrind上運(yùn)行良好，但是在出口處出現(xiàn)segfaults，您可能會發(fā)現(xiàn)?--run-libc-freeres=no修復(fù)盡管可能會錯誤地報告空間漏洞?libc.so。

此選項(xiàng)僅在運(yùn)行Linux或Solaris C ++程序上的Valgrind時才有用。

libstdc++.so由g ++編譯的所有C ++程序使用的GNU標(biāo)準(zhǔn)C ++庫（）可能會為自己的用途分配內(nèi)存。通常，當(dāng)程序結(jié)束時，它不會釋放內(nèi)存，因?yàn)閮?nèi)核在進(jìn)程退出時會回收所有進(jìn)程資源，所以它只會減慢速度。

gcc作者意識到，當(dāng)在出口處進(jìn)行泄漏檢查時，此行為會導(dǎo)致漏洞檢查器（如Valgrind）在libstdc ++中錯誤地報告泄漏。為了避免這種情況，他們提供了一個__gnu_cxx::__freeres?專門用于使libstdc ++釋放其已分配的所有內(nèi)存的例程。因此，Memcheck嘗試__gnu_cxx::__freeres在退出時運(yùn)行?。

為了靈活性和不可預(yù)見的問題?__gnu_cxx::__freeres，選擇?--run-cxx-freeres=no存在，盡管可能錯誤地報告空間泄漏?libstdc++.so。

通過Valgrind的其他提示，以非標(biāo)準(zhǔn)或危險的方式稍微修改模擬行為，可能有助于模擬奇怪的功能。默認(rèn)情況下不啟用任何提示。謹(jǐn)慎使用！目前已知的提示有：

• lax-ioctls:?對于ioctl處理非常松懈;?唯一的假設(shè)是大小是正確的。寫入時不需要初始化完整的緩沖區(qū)。沒有這個，使用一些設(shè)備驅(qū)動程序與大量的奇怪的ioctl命令變得非常麻煩。

• fuse-compatible:?對可能在FUSE文件系統(tǒng)中阻塞的某些系統(tǒng)調(diào)用啟用特殊處理。在使用一個線程來管理FUSE文件系統(tǒng)的多線程程序上運(yùn)行Valgrind并且另一個線程訪問該文件系統(tǒng)時，這可能是必需的。

• enable-outer:?當(dāng)運(yùn)行程序本身是Valgrind時，啟用了一些特殊的魔法。

• no-inner-prefix:?禁止>在外部Valgrind運(yùn)行的內(nèi)部Valgrind中，在每個stdout或stderr輸出行前面打印前綴。當(dāng)在外部/內(nèi)部設(shè)置中運(yùn)行Valgrind回歸測試時，這是非常有用的。請注意，前綴>將始終打印在內(nèi)部調(diào)試日志記錄行的前面。

• no-nptl-pthread-stackcache:?這個提示僅在Linux上運(yùn)行Valgrind時才有用。

  libpthread.sopthread程序使用的GNU glibc pthread庫（）維護(hù)一個pthread棧緩存。當(dāng)pthread終止時，用于pthread棧的內(nèi)存和一些線程本地存儲相關(guān)數(shù)據(jù)結(jié)構(gòu)并不總是直接釋放。這個內(nèi)存被保存在高速緩存中（達(dá)到一定的大小），如果啟動了一個新的線程，那么這個內(nèi)存被重新使用。

  這個緩存導(dǎo)致helgrind工具在這個緩存的內(nèi)存上報告一些錯誤的正面競爭條件錯誤，因?yàn)閔elgrind不了解內(nèi)部glibc緩存同步原語。所以，當(dāng)使用helgrind時，禁用緩存有助于避免錯誤的正面競爭條件，特別是當(dāng)使用線程本地存儲變量（例如使用?__thread限定符的變量）時。

  當(dāng)使用memcheck工具時，禁用高速緩存可確保glibc處理__thread變量所使用的內(nèi)存在線程終止時直接釋放。

  注意：Valgrind使用glibc堆棧緩存實(shí)現(xiàn)的一些內(nèi)部知識以及檢查pthread庫的調(diào)試信息來禁用緩存。因此，這種技術(shù)有些脆弱，并且可能對所有g(shù)libc版本都無效。這已經(jīng)在各種平臺上通過各種glibc版本（例如2.11,2.16,2.18）成功測試。

• lax-doors:?（僅限Solaris）對于無法識別的門文件描述符，關(guān)于門系統(tǒng)調(diào)用處理非常松懈。不需要在寫入時初始化完整的緩沖區(qū)。沒有這一點(diǎn)，使用具有完全專有語義的libdoor（3LIB）功能的程序可能會報告大量的誤報。

該--fair-sched選項(xiàng)控制Valgrind使用的鎖定機(jī)制來串行線程執(zhí)行。鎖定機(jī)制控制線程的安排方式，不同的設(shè)置在公平性和性能之間進(jìn)行不同的權(quán)衡。有關(guān)Valgrind線程序列化方案及其對性能和線程調(diào)度的影響的更多詳細(xì)信息，請參閱?計劃和多線程性能。

• 該值--fair-sched=yes?激活公平的調(diào)度程序。簡而言之，如果多個線程準(zhǔn)備運(yùn)行，線程將以輪循方式進(jìn)行安排。該機(jī)制在所有平臺或Linux版本上都不可用。如果不可用，則使用--fair-sched=yes會導(dǎo)致Valgrind終止并出現(xiàn)錯誤。

  如果您在Valgrind上運(yùn)行交互式多線程程序（例如Web瀏覽器），則可能會發(fā)現(xiàn)此設(shè)置會提高整體響應(yīng)能力。

• 該值--fair-sched=try?激活公平調(diào)度（如果在平臺上可用）。否則會自動回退--fair-sched=no。

• 該值--fair-sched=no激活一個不能保證線程準(zhǔn)備運(yùn)行的線程之間的公平性，但通常給出最高性能的調(diào)度器。

處理來自該平臺的默認(rèn)內(nèi)核的較小變體的系統(tǒng)調(diào)用和ioctl。這對于在黑客內(nèi)核上運(yùn)行或者支持非標(biāo)準(zhǔn)ioctl的內(nèi)核模塊非常有用。謹(jǐn)慎使用。如果你不明白這個選項(xiàng)是什么，那么你幾乎肯定不需要它。目前已知的變體是：

• bproc：支持sys_brocx86上的?系統(tǒng)調(diào)用。這是用于在BProc上運(yùn)行的，它是標(biāo)準(zhǔn)Linux的一小部分變體，有時用于構(gòu)建集群。

• android-no-hw-tls：ARM版Android模擬器的一些版本不提供硬件TLS（線程本地狀態(tài)）寄存器，Valgrind在啟動時崩潰。使用此變體選擇TLS的軟件支持。

• android-gpu-sgx5xx：使用它來支持在Android設(shè)備上處理PowerVR SGX 5XX系列GPU的專有ioctl。未選擇此項(xiàng)不會導(dǎo)致穩(wěn)定性問題，但可能會導(dǎo)致Memcheck在程序執(zhí)行GPU特定的ioctl之后報告錯誤的錯誤。

• android-gpu-adreno3xx：同樣地，使用它來支持在Android設(shè)備上處理高通Adreno 3XX系列GPU的專有ioctl。

一些遞歸算法，例如平衡二叉樹實(shí)現(xiàn)，創(chuàng)建許多不同的堆棧跟蹤，每個包含循環(huán)的調(diào)用。一個周期被定義為由零個或多個其他程序計數(shù)器值分隔的兩個相同的程序計數(shù)器值。然后，Valgrind可能會使用大量內(nèi)存來存儲所有這些堆棧跟蹤。考慮到這種堆棧跟蹤包含重復(fù)的不感興趣的遞歸調(diào)用而不是更有趣的信息，例如已經(jīng)發(fā)起遞歸調(diào)用的函數(shù)，這是一個很差的內(nèi)存使用。

該選項(xiàng)--merge-recursive-frames=<number>?指示Valgrind檢測并合并大小最多為<number>?幀的遞歸調(diào)用循環(huán)。當(dāng)檢測到這樣的循環(huán)時，Valgrind將堆棧跟蹤中的循環(huán)記錄為唯一的程序計數(shù)器。

值0（默認(rèn)值）不會導(dǎo)致遞歸調(diào)用合并。值為1將導(dǎo)致簡單遞歸算法（例如，階乘實(shí)現(xiàn)）的堆棧跟蹤被折疊。通常需要2的值來折疊由遞歸算法（如二叉樹，快速排序等）等產(chǎn)生的堆棧跟蹤。更復(fù)雜的遞歸算法可能需要更高的值。

注意：通過分析程序計數(shù)器值來檢測遞歸調(diào)用。通過查看函數(shù)名稱來檢測它們。

Valgrind以小碎片（基本塊）翻譯和調(diào)整程序的機(jī)器代碼。翻譯存儲在翻譯高速緩存中，該高速緩存分為多個部分（扇區(qū)）。如果緩存已滿，則包含最舊的翻譯的扇區(qū)將被清空并重新使用。如果需要這些舊的翻譯，Valgrind必須重新翻譯和重新設(shè)備相應(yīng)的機(jī)器代碼，這是昂貴的。如果程序的“執(zhí)行指令”工作集很大，則通過減少所需的翻譯次數(shù)，增加扇區(qū)數(shù)量可以提高性能。部門按需分配。一旦分配，一個部門永遠(yuǎn)不會被釋放，并占據(jù)相當(dāng)大的空間，--avg-transtab-entry-size?取決于工具和值（Memcheck每個扇區(qū)大約40 MB）。使用選項(xiàng)--stats=yes來獲取有關(guān)部門使用的內(nèi)存以及部門分配和回收的準(zhǔn)確信息。

翻譯基本塊的平均大小。該平均尺寸用于確定扇區(qū)的大小。每個工具提供要使用的默認(rèn)值。如果此默認(rèn)值太小，則翻譯扇區(qū)將變得過快。如果此默認(rèn)值太大，則翻譯部分內(nèi)存的很大一部分將不被使用。請注意，基本塊平移的平均大小取決于工具，并且可能取決于工具選項(xiàng)。例如，memcheck選項(xiàng)--track-origins=yes?增加了基本塊轉(zhuǎn)換的大小。使用--avg-transtab-entry-size調(diào)整扇區(qū)的大小，既可以獲取內(nèi)存或避免過多的重譯。

為了避免與某些系統(tǒng)庫的潛在沖突，Valgrind不會使用下面的地址空間--aspace-minaddr值，保留它，以防庫中特別要求該區(qū)域內(nèi)存。所以根據(jù)平臺，Valgrind猜測到一些“悲觀”的價值。在Linux上，默認(rèn)情況下，Valgrind避免使用第一個64MB，即使這個完整區(qū)域通常沒有沖突。您可以使用該選項(xiàng)--aspace-minaddr使您的內(nèi)存饑餓應(yīng)用程序從更多的這種較低的內(nèi)存中受益。另一方面，如果遇到?jīng)_突，增加aspace-minaddr值可能會解決它。沖突通常會在地址空間較低的范圍內(nèi)出現(xiàn)mmap故障。address提供的頁面必須對齊，并且必須等于或大于0x1000（4KB）。要在平臺上找到默認(rèn)值，請執(zhí)行以下操作?valgrind -d -d date 2>&1 | grep -i minaddr。已知低于0x10000（64KB）的值會在某些分布上產(chǎn)生問題。

對于每個線程，Valgrind需要自己的“私有”堆棧。這些堆棧的默認(rèn)大小在很大程度上是大小尺寸的，因此在大多數(shù)情況下應(yīng)該是足夠的。如果尺寸太小，Valgrind將會發(fā)生故障。在分裂之前，Valgrind可能在接近極限時發(fā)出警告。

--valgrind-stacksize如果產(chǎn)生這樣的（不太可能）警告，或者由于分段違規(guī)導(dǎo)致Valgrind死亡，?請使用該選項(xiàng)。在分離大量C ++符號時已經(jīng)看到這種分段違例。

如果您的應(yīng)用程序使用許多線程并需要大量內(nèi)存，您可以通過使用該選項(xiàng)減小這些Valgrind堆棧的大小來獲得一些內(nèi)存--valgrind-stacksize。

啟用后，Valgrind在某些??情況下會發(fā)出關(guān)于CPU仿真的警告。這些通常不是有趣的。

當(dāng)soname匹配的共享對象sonamepatt加載到進(jìn)程中時，檢查其導(dǎo)出的所有文本符號。如果沒有匹配fnnamepatt，打印錯誤信息并放棄運(yùn)行。這使得有可能確保運(yùn)行不會繼續(xù)，除非給定的共享對象包含特定的函數(shù)名稱。

雙方sonamepatt并?fnnamepatt可以用通常的寫入??和*通配符。例如：":*libc.so*:foo?bar"。您可以使用冒號以外的字符分隔兩個模式。第一個字符和分隔符相同只是重要的。例如，上面的例子也可以寫成"Q*libc.so*Qfoo?bar"。?--require-text-symbol允許多個標(biāo)志，在這種情況下，將檢查加載到進(jìn)程中的共享對象。

其目的是支持可靠使用已標(biāo)記的庫。例如，假設(shè)我們有一個GCC的版本，?libgomp.so其中已經(jīng)標(biāo)注了注釋以支持Helgrind。將錯誤的，未注釋的加載到應(yīng)用程序中是太容易和混亂了?libgomp.so。所以這個想法是：例如在標(biāo)記的庫中添加一個文本符號annotated_for_helgrind_3_6，然后給出標(biāo)志?--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6?，以便libgomp.so加載時，Valgrind掃描其符號表，如果符號不存在，則運(yùn)行中止，而不是與未標(biāo)記的圖書館保持沉默。請注意，您應(yīng)該將整個標(biāo)記放在引號中，以阻止擴(kuò)展*?和?通配符的擴(kuò)展。

加載共享庫時，Valgrind會檢查庫中必須更換或包裝的函數(shù)。例如，Memcheck用自己的版本替換一些字符串和內(nèi)存函數(shù)（strchr，strlen，strcpy，memchr，memcpy，memmove等）。這樣的替換通常僅在共享庫中進(jìn)行，其共享庫的soname匹配預(yù)定義的soname模式（例如?libc.so*在linux上）。默認(rèn)情況下，除了分配函數(shù)（malloc，free，calloc，memalign，realloc，operator new，operator delete等）之外，靜態(tài)鏈接二進(jìn)制或替代庫不進(jìn)行替換。默認(rèn)情況下，這種分配函數(shù)被截取任何共享庫或可執(zhí)行文件，如果它們被導(dǎo)出為全局符號。?這意味著如果找到替換分配庫（如tcmalloc），則默認(rèn)情況下也會攔截其函數(shù)。--soname-synonyms在某些情況下，替換可以指定一個額外的同義詞模式，從而給予更換的靈活性。或防止截取所有公共分配符號。

目前，這種靈活性只允許使用同義詞的malloc相關(guān)功能somalloc。這個同義詞可用于執(zhí)行malloc相關(guān)功能的標(biāo)準(zhǔn)替換的所有工具（例如memcheck，massif，drd，helgrind，exp-dhat，exp-sgcheck）。

• 替代的malloc庫：使用soname?mymalloclib.so（而不是任何其他）替換特定備用庫中的malloc相關(guān)函數(shù)，給出選項(xiàng)--soname-synonyms=somalloc=mymalloclib.so。可以使用一個模式來匹配多個庫的聲名。例如，--soname-synonyms=somalloc=*tcmalloc*?將匹配tcmalloc庫（native，debug，profiled，... tcmalloc變體）的所有變體的soname。

  注意：可以使用readelf實(shí)用程序檢索elf共享庫的soname。

• 靜態(tài)鏈接庫中的替換是通過使用NONE模式來完成的。例如，如果您鏈??接libtcmalloc.a，并且只想攔截可執(zhí)行文件（和標(biāo)準(zhǔn)庫）本身的malloc相關(guān)函數(shù)，而不是任何其他共享庫，則可以給出該選項(xiàng)--soname-synonyms=somalloc=NONE。請注意，NONE模式將匹配主可執(zhí)行文件和任何沒有soname的共享庫。

• 要運(yùn)行用于Linux的“默認(rèn)”Firefox版本，其中JEMalloc鏈接到主可執(zhí)行文件，請使用--soname-synonyms=somalloc=NONE。

• 為了僅攔截默認(rèn)系統(tǒng)庫中的分配符號，但不能在任何其他共享庫或定義public malloc或operator new相關(guān)函數(shù)的可執(zhí)行文件中使用不存在的庫名稱--soname-synonyms=somalloc=nouserintercepts?（如果nouserintercepts可以是任何不存在的庫名稱）。

• 搜索動態(tài)（運(yùn)行時）鏈接器的共享庫被排除在搜索全局公共符號之外，如malloc相關(guān)函數(shù)（由somalloc同義詞標(biāo)識）。