valgrind.bin - Інтернет у хмарі

ПРОГРАМА:

ІМ'Я

valgrind - набір інструментів для налагодження та профілювання програм

СИНТАКСИС

валгринд [valgrind-опції] [ваша програма] [параметри вашої програми]

ОПИС

Вальгрінд це гнучка програма для налагодження та профілювання виконуваних файлів Linux. Воно складається
ядра, яке забезпечує синтетичний ЦП у програмному забезпеченні, і серію налагодження та
інструменти профілювання. Архітектура є модульною, тому нові інструменти можна легко створювати
не порушуючи існуючої конструкції.

Деякі з наведених нижче параметрів працюють з усіма інструментами Valgrind, а деякі працюють лише з ними
кілька або один. Розділ ПАРАМЕТРІВ MEMCHECK та ті, що знаходяться під ним, описують конкретні інструменти
Варіанти.

Ця сторінка посібника охоплює лише основне використання та параметри. Для отримання більш вичерпної інформації,
будь ласка, перегляньте документацію HTML у вашій системі:
$INSTALL/share/doc/valgrind/html/index.html або онлайн:
http://www.valgrind.org/docs/manual/index.html.

ІНСТРУМЕНТ ВИБІР ВАРІАНТИ

Єдиний найважливіший варіант.

--інструмент= [за замовчуванням: memcheck]
Запустіть інструмент Valgrind під назвою назва інструменту, наприклад, memcheck, cachegrind, callgrind, helgrind,
drd, масив, лакей, немає, exp-sgcheck, exp-bbv, exp-dhat тощо.

BASIC ВАРІАНТИ

Ці параметри працюють з усіма інструментами.

-h --допомога
Показати довідку для всіх параметрів, як для ядра, так і для вибраного інструмента. Якщо варіант
повторюється еквівалентно дачі --help-debug.

--help-debug
Такий же, як --допомога, а також перелічує параметри налагодження, які зазвичай корисні лише для
Розробники Valgrind.

-- версія
Показати номер версії ядра Valgrind. Інструменти можуть мати власну версію
числа. Існує схема, яка гарантує, що інструменти виконуються лише тоді, коли ядро
версія, з якою вони, як відомо, працюють. Це було зроблено, щоб мінімізувати шанси
дивні проблеми, що виникають через несумісність версій інструментів і ядра.

-q, --спокійно
Виконуйте безшумно і друкуйте лише повідомлення про помилки. Корисно, якщо ви виконуєте регресію
тести або мати інше автоматизоване обладнання для тестування.

-v, -багатослівний
Будьте більш багатослівними. Надає додаткову інформацію про різні аспекти вашої програми, наприклад:
завантажені спільні об’єкти, використані придушення, хід інструментів
і механізми виконання, а також попередження про незвичайну поведінку. Повторення варіанту
підвищує рівень багатослівності.

--trace-children= [за замовчуванням: немає]
Якщо ввімкнено, Valgrind буде відстежувати підпроцеси, ініційовані за допомогою Exec система
дзвонити. Це необхідно для багатопроцесорних програм.

Зауважте, що Valgrind відстежує дочірнє значення a вилка (було б важко не зробити,
з вилка створює ідентичну копію процесу), тому цей варіант, можливо, поганий
названий. Однак більшість дітей о вилка дзвінки негайно дзвоніть Exec все одно.

--trace-children-skip=patt1,patt2,...
Цей параметр діє лише тоді, коли --trace-children=так вказано. Це дозволяє
деяких дітей можна пропустити. Параметр приймає список шаблонів, розділених комами
імена дочірніх виконуваних файлів, які Valgrind не повинен відстежувати. Візерунки можуть
включити метасимволи ? і *, які мають звичайне значення.

Це може бути корисно для обрізання нецікавих гілок з дерева процесів буття
бігати на Valgrind. Але при його використанні слід бути обережним. Коли Valgrind пропускає трасування
у виконуваний файл, він не просто пропускає трасування цього виконуваного файлу, він також пропускає
відстеження будь-яких дочірніх процесів виконуваного файлу. Іншими словами, прапор не має
просто спричиняє зупинку трасування на вказаних виконуваних файлах - він пропускає трасування
цілі піддерева процесу, вкорінені в будь-якому із зазначених виконуваних файлів.

--trace-children-skip-by-arg=patt1,patt2,...
Це те саме, що --trace-children-skip, з однією відмінністю: рішення щодо
чи слід відстежувати дочірній процес, вирішується шляхом перевірки аргументів дитини
процесу, а не ім'я його виконуваного файлу.

--дитина-тиха-після-вилки= [за замовчуванням: немає]
Якщо ввімкнено, Valgrind не показуватиме жодних результатів налагодження чи журналу для дитини
процес, що виникає в результаті а вилка дзвонити. Це може зробити вихід менш заплутаним (хоча
більше вводить в оману), коли йдеться про процеси, які створюють дітей. Це особливо
корисно в поєднанні з --trace-children=. Використання цієї опції також активно
рекомендується, якщо ви вимагаєте виведення XML (--xml=так), оскільки інакше XML з
дитина і батьки можуть змішатися, що зазвичай робить його марним.

--vgdb= [за замовчуванням: так]
Valgrind надасть функціональність "gdbserver", коли --vgdb=так or --vgdb=повний is
вказано. Це дозволяє зовнішньому налагоджувачу GNU GDB контролювати та налагоджувати вашу програму
коли він працює на Valgrind. --vgdb=повний несе значні витрати на продуктивність, але
забезпечує більш точні контрольні точки та контрольні точки. Див. Налагодження програми за допомогою
gdbserver і GDB від Valgrind для детального опису.

Якщо вбудований gdbserver увімкнено, але наразі не використовується gdb, vgdb
Утиліта командного рядка може надсилати "команди моніторингу" до Valgrind з оболонки. The
Ядро Valgrind надає набір команд монітора Valgrind. За бажанням можна використовувати інструмент
надайте команди монітора для певних інструментів, які задокументовані в спеціальному інструменті
глави.

--vgdb-error= [за замовчуванням: 999999999]
Використовуйте цей параметр, коли Valgrind gdbserver увімкнено за допомогою --vgdb=так or --vgdb=повний.
Інструменти, які повідомляють про помилки, чекатимуть повідомлення про "число" помилок, перш ніж заморозити
програму і чекає, коли ви підключитеся до GDB. Звідси випливає, що значення дорівнює нулю
призведе до запуску gdbserver до виконання вашої програми. Це
зазвичай використовується для вставки точок зупинки GDB перед виконанням, а також працює з інструментами
які не повідомляють про помилки, наприклад Massif.

--vgdb-stop-at= [за замовчуванням: жоден]
Використовуйте цей параметр, коли Valgrind gdbserver увімкнено за допомогою --vgdb=так or --vgdb=повний.
Valgrind gdbserver буде викликатися для кожної помилки після --vgdb-помилка були
повідомили. Ви також можете попросити Valgrind gdbserver бути викликаним для інших
події, визначені одним із таких способів:

· розділений комами список з одного або кількох введення в експлуатацію вихід валгріндабексит.

Значення введення в експлуатацію вихід валгріндабексит відповідно вказують на виклик gdbserver
до виконання вашої програми, після останньої інструкції вашої програми, на
Ненормальний вихід Valgrind (наприклад, внутрішня помилка, брак пам’яті, ...).

Примітка: введення в експлуатацію та --vgdb-помилка=0 обидва призведуть до виклику Valgrind gdbserver
до того, як ваша програма буде виконана. The --vgdb-помилка=0 додатково спричинить ваш
програма для зупинки на всіх наступних помилках.

· всі вказати повний комплект. Це еквівалентно
--vgdb-stop-at=запуск, вихід, valgrindabexit.

· ніхто для порожнього набору.

--track-fds= [за замовчуванням: немає]
Якщо ввімкнено, Valgrind роздрукує список відкритих дескрипторів файлів під час виходу або ввімкнення
запит за допомогою команди gdbserver monitor v.info open_fds. Разом з кожним файлом
дескриптор друкує стек зворотного трасування місця відкриття файлу та будь-яких деталей
пов’язаний з дескриптором файлу, таким як ім’я файлу або деталі сокета.

--time-stamp= [за замовчуванням: немає]
Якщо ввімкнено, кожному повідомленню передує вказівка ​​настінного годинника, який минув
час з моменту запуску, виражений у днях, годинах, хвилинах, секундах і мілісекундах.

--log-fd= [за замовчуванням: 2, stderr]
Вказує, що Valgrind має надсилати всі свої повідомлення до вказаного файлу
дескриптор. За замовчуванням, 2, є стандартним каналом помилок (stderr). Зауважте, що це може
перешкоджати власному використанню клієнтом stderr, як буде результатом Valgrind
перемежовується з будь-яким виводом, який клієнт надсилає до stderr.

--log-file=
Вказує, що Valgrind має надсилати всі свої повідомлення до вказаного файлу. Якщо
ім'я файлу порожнє, це спричиняє переривання. Є три спеціальні специфікатори формату
можна використовувати в імені файлу.

%p замінюється на поточний ідентифікатор процесу. Це дуже корисно для програми, яка
викликати кілька процесів. ПОПЕРЕДЖЕННЯ: якщо ви використовуєте --trace-children=так і ваша програма
викликає декілька процесів АБО ваша програма розгалужується без виклику exec потім, і
ви не використовуєте цей специфікатор (або %q специфікатор нижче), вихідні дані Valgrind зі всіх
ці процеси увійдуть в один файл, можливо, перемішаний і, можливо, неповний.

%q{FOO} замінюється вмістом змінної середовища FOO, Якщо {FOO}
частина неправильно сформована, це спричиняє переривання. Цей специфікатор потрібен рідко, але дуже
корисно за певних обставин (наприклад, під час виконання програм MPI). Ідея в тому, що ти
вкажіть змінну, яка буде встановлена ​​по-різному для кожного процесу в роботі, for
Наприклад, BPROC_RANK або будь-який інший, застосовний у вашій установці MPI. Якщо названий
змінна середовища не встановлена, це спричиняє переривання. Зауважте, що в деяких оболонках {
та } символів може знадобитися екранувати за допомогою зворотної косої риски.

%% замінюється на %.

Якщо % за яким слідує будь-який інший символ, це спричиняє переривання.

Якщо ім'я файлу вказує відносне ім'я файлу, воно поміщається в ініціал програми
робочий каталог : це поточний каталог, коли програма запустила його
виконання після fork або після exec. Якщо він визначає абсолютне ім’я файлу (тобто.
починається з '/'), потім він поміщається туди.

--log-socket=
Вказує, що Valgrind має надсилати всі свої повідомлення на вказаний порт за адресою
вказана IP-адреса. Порт може бути опущений, у цьому випадку використовується порт 1500. Якщо
не можна встановити підключення до вказаного сокета, Valgrind повертається до запису
вивести стандартну помилку (stderr). Цей параметр призначений для використання в
у поєднанні з програмою valgrind-listener. Для отримання додаткової інформації див
коментар у посібнику.

ПОМИЛКИ ВАРІАНТИ

Ці параметри використовуються всіма інструментами, які можуть повідомляти про помилки, наприклад Memcheck, але ні
Cachegrind.

--xml= [за замовчуванням: немає]
Якщо ввімкнено, важливі частини виводу (наприклад, повідомлення про помилки інструмента) будуть введені
Формат XML, а не звичайний текст. Крім того, XML-вивід буде надіслано до a
інший вихідний канал, ніж вихід простого тексту. Тому ви також повинні використовувати його
of --xml-fd, --xml-файл or --xml-сокет щоб вказати, куди буде надіслано XML.

Менш важливі повідомлення все одно будуть надруковані у вигляді простого тексту, а тому XML
вихідний і вихідний текст простого тексту надсилаються в різні вихідні канали (призначення
вихід простого тексту все ще контролюється --log-fd, --файл журналу та --лог-розетка)
це не повинно викликати проблем.

Цей параметр спрямований на полегшення життя інструментів, які споживають вихідні дані Valgrind як
введення, наприклад інтерфейси графічного інтерфейсу. Наразі ця опція працює з Memcheck, Helgrind,
DRD і SGcheck. Формат виводу вказується у файлі
docs/internals/xml-output-protocol4.txt у дереві джерел для Valgrind 3.5.0 або
пізніше.

Рекомендовані параметри для передачі графічного інтерфейсу під час запиту виведення XML: --xml=так
щоб увімкнути вихід XML, --xml-файл щоб надіслати вихід XML на (імовірно, вибраний GUI)
файл, --файл журналу щоб надіслати вихід простого тексту до другого файлу, вибраного GUI,
--дитина-тиха-після-вилки=так та -q щоб обмежити вихід простого тексту критичним
повідомлення про помилки, створені самим Valgrind. Наприклад, помилка прочитання вказаного
файл supressions вважається критичним повідомленням про помилку. Таким чином, для успішного
запустити текстовий вихідний файл буде порожнім. Але якщо він не порожній, то він буде містити
важлива інформація, про яку повинен знати користувач GUI.

--xml-fd= [за замовчуванням: -1, вимкнено]
Вказує, що Valgrind має відправити свій XML-вивід до вказаного дескриптора файлу.
Його необхідно використовувати разом з --xml=так.

--xml-файл=
Вказує, що Valgrind має відправити свій XML-вивід у вказаний файл. Це повинно бути
використовується разом з --xml=так. Будь-який %p or %q послідовності, що відображаються в імені файлу
розширюються точно так само, як і для --файл журналу. Дивіться опис
of --файл журналу for details.

--xml-socket=
Вказує, що Valgrind має відправити свій XML-вивід на вказаний порт на вказаному
IP-адреса. Його необхідно використовувати разом з --xml=так. Форма аргументації така
те саме, що використовується --лог-розетка. Дивіться опис --лог-розетка для подальшого
подробиці

--xml-user-comment=
Вбудовує додатковий рядок коментарів користувача на початку виводу XML. Працює лише тоді, коли
--xml=так уточнюється; інакше ігнорується.

--demangle= [за замовчуванням: так]
Увімкнути/вимкнути автоматичне розшифровування (декодування) імен C++. Увімкнено за замовчуванням. Коли
увімкнено, Valgrind намагатиметься перекласти закодовані імена C++ назад у щось
наближається до оригіналу. Demangler обробляє символи, зіпсовані g++ версії 2.X,
3.X і 4.X.

Важливим фактом демантингу є те, що імена функцій згадуються в придушеннях
файли повинні бути в пошкодженому вигляді. Valgrind не розбирає імена функцій, коли
пошук застосовних придушень, тому що в іншому випадку це призведе до придушення
вміст файлу залежить від стану механізму розбирання Valgrind, а також повільний
узгодження придушення вниз.

--num-callers= [за замовчуванням: 12]
Вказує максимальну кількість записів, що відображаються в трассах стека, які ідентифікують програму
місця розташування. Зауважте, що помилки фіксуються лише з використанням чотирьох верхніх розташування функцій
(місце в поточній функції та її трьох безпосередніх викликів). Так це
не впливає на загальну кількість повідомлених помилок.

Максимальне значення для цього становить 500. Зауважте, що вищі налаштування змусять Valgrind запускати a
трохи повільніше і займає трохи більше пам’яті, але може бути корисним при роботі з
програми з глибоко вкладеними ланцюжками викликів.

--unw-stack-scan-thresh= [за замовчуванням: 0] , --unw-stack-scan-frames= [за замовчуванням:
5]
Підтримка стекового сканування доступна лише для об’єктів ARM.

Ці прапорці дозволяють і керують розкручуванням стека шляхом сканування стека. Коли нормальний
Механізми розгортання стеку -- використання записів Dwarf CFI та слідування вказівника кадру
-- помилка, сканування стека може відновити трасування стека.

Зауважте, що сканування стека є неточним, евристичним механізмом, який може дати дуже багато
оманливі результати або їх немає взагалі. Його слід використовувати тільки в екстрених випадках, коли це нормально
розмотування не вдається, і, тим не менш, важливо мати трасування стека.

Сканування стека – це проста техніка: розмотувач зчитує слова зі стека та
намагається вгадати, які з них можуть бути зворотними адресами, перевіряючи, чи вони
вкажіть відразу після інструкцій виклику ARM або Thumb. Якщо так, слово додається до
зворотна траса.

Основна небезпека виникає, коли повертається виклик функції, залишаючи адресу повернення
відкрито, і викликається нова функція, але нова функція не замінює стару
адреса. Результатом цього є те, що зворотне трасування може містити записи для функцій
які вже повернулися, і тому будуть дуже заплутаними.

Друге обмеження цієї реалізації полягає в тому, що вона буде сканувати лише сторінку (4 КБ,
зазвичай), що містить початковий покажчик стека. Якщо кадри стека великі, це
може призвести до того, що в трасі буде присутні лише декілька (або навіть жодна). Крім того, якщо ви
не пощастило і має початковий покажчик стека в кінці сторінки, що містить, the
сканування може пропустити всі цікаві кадри.

За замовчуванням сканування стека вимкнено. Звичайним варіантом використання є запит на це, коли a
Інакше трасування стека було б дуже коротким. Отже, щоб увімкнути його, використовуйте
--unw-stack-scan-thresh=число. Це вимагає від Valgrind спробувати використовувати сканування стека
"розширити" стек трас, які містять менше числових кадрів.

Якщо сканування стека все ж таки має місце, воно генеруватиме не більше ніж кількість кадрів
визначено --unw-stack-scan-frames. Як правило, стекове сканування генерує дуже багато
сміття записів, що це значення встановлено на низьке значення (5) за замовчуванням. Ні в якому разі не буде
буде створено трасування стека, що перевищує значення, зазначене параметром --num-callers.

--error-limit= [за замовчуванням: так]
Якщо ввімкнено, Valgrind припиняє повідомляти про помилки після 10,000,000 1,000 XNUMX в цілому або XNUMX XNUMX
різні, були помічені. Це потрібно для того, щоб зупинити механізм відстеження помилок
стають величезними накладними витратами на продуктивність у програмах з великою кількістю помилок.

--error-exitcode= [за замовчуванням: 0]
Вказує альтернативний код виходу, який повертається, якщо Valgrind повідомляє про помилки в файлі
бігти. Якщо встановлено значення за замовчуванням (нуль), значення, що повертається від Valgrind, завжди буде
бути поверненим значенням процесу, що моделюється. Якщо встановлено ненульове значення, це
замість цього повертається значення, якщо Valgrind виявляє будь-які помилки. Це корисно для використання
Valgrind як частина автоматизованого набору тестів, оскільки він полегшує виявлення тесту
випадки, для яких Valgrind повідомляв про помилки, просто перевіривши коди повернення.

--error-markers= , [за замовчуванням: жоден]
Коли помилки виводяться як звичайний текст (тобто XML не використовується), -- маркери помилок доручає
вивести рядок, що містить починати (кінець) рядок перед (після) кожної помилки.

Такі маркерні лінії полегшують пошук помилок та/або вилучення помилок у файлі
вихідний файл, який містить помилки valgrind, змішані з виводом програми.

Зауважте, що пусті маркери приймаються. Таким чином, можна використовувати лише маркер початку (або кінця).
можливо.

--sigill-diagnostics= [за замовчуванням: так]
Увімкнути/вимкнути друк діагностики неправомірних інструкцій. Увімкнено за замовчуванням, але
за замовчуванням вимкнено, коли --спокійно надається. Значення за замовчуванням завжди може бути явним
перевизначено, надавши цю опцію.

Якщо ввімкнено, будь-коли буде надруковано попередження разом із деякими діагностиками
зустрічається інструкція, яку Valgrind не може декодувати або перекласти, до
Програма отримує сигнал SIGILL. Часто незаконна інструкція вказує на помилку в
програма або відсутня підтримка для певної інструкції в Valgrind. Але деякі
Програми свідомо намагаються виконати інструкцію, яка може бути відсутньою та перехоплювати
сигнал SIGILL для виявлення функцій процесора. Використання цього прапора дає змогу
уникайте діагностичних результатів, які ви інакше отримали б у таких випадках.

--show-below-main= [за замовчуванням: немає]
За замовчуванням трасування стека для помилок не показують жодних функцій, які відображаються під ним основний
тому що більшість часу це нецікава бібліотека C та/або gobbledygook.
Як варіант, якщо основний відсутня в трасі стека, сліди стека не відображатимуться
будь-які функції нижче основний-подібні функції, такі як glibc __libc_start_main.
Крім того, якщо основний-подібні функції присутні в трасі, вони нормовані як
(нижче головне), щоб зробити вихід більш детермінованим.

Якщо цей параметр увімкнено, відображатимуться всі записи трасування стека та основний-Як
функції не будуть нормалізовані.

--повний шлях-після= [за замовчуванням: НЕ Показувати джерело шляхи]
За замовчуванням Valgrind показує лише імена файлів у стеку, але не повні шляхи до них
вихідні файли. При використанні Valgrind у великих проектах, у яких знаходяться джерела
кілька різних каталогів, це може бути незручно. --повний шлях-після забезпечує
гнучке рішення цієї проблеми. Якщо цей параметр присутній, шлях до кожного
буде показано вихідний файл з наступним важливим застереженням: if рядок знайдено в с
шлях, потім шлях до включно рядок опущено, інакше буде показано шлях
незмінений. Зауважте, що рядок не обов’язково бути префіксом шляху.

Наприклад, розглянемо файл з ім’ям /home/janedoe/blah/src/foo/bar/xyzzy.c. Уточнення
--fullpath-after=/home/janedoe/blah/src/ змусить Valgrind відображати назву як
foo/bar/xyzzy.c.

Оскільки рядок не обов’язково повинен бути префіксом, --fullpath-after=src/ буде виробляти
той самий вихід. Це корисно, коли шлях містить довільні машинно згенеровані
символів. Наприклад, шлях /my/build/dir/C32A1B47/blah/src/foo/xyzzy може бути
обрізаний до foo/xyzzy за допомогою --fullpath-after=/blah/src/.

Якщо ви просто хочете побачити повний шлях, просто вкажіть порожній рядок:
--повний шлях-після=. Це не окремий випадок, просто логічний наслідок
вище правила.

Нарешті, ви можете використовувати --повний шлях-після кілька разів. Будь-яка поява його викликає
Valgrind, щоб перейти до створення повних шляхів і застосування вищезгаданого правила фільтрації. Кожен
вироблений шлях порівнюється з усіма --повний шлях-після-вказані рядки в
вказано порядок. Перший рядок, який відповідає, обрізає шлях як
описані вище. Якщо жоден з них не збігається, відображається повний шлях. Це полегшує відрізання
префікси, коли джерела беруться з кількох непов’язаних каталогів.

--extra-debuginfo-path= [за замовчуванням: невизначених та невикористаний]
За замовчуванням Valgrind шукає в кількох добре відомих шляхах об’єкти налагодження, наприклад
/usr/lib/debug/.

Однак можуть бути сценарії, коли ви можете помістити об’єкти налагодження в an
довільне розташування, наприклад зовнішня пам’ять під час запуску Valgrind на мобільному пристрої
з обмеженим локальним сховищем. Іншим прикладом може бути ситуація, коли у вас немає
дозвіл на встановлення пакетів об’єктів налагодження в системі, де ви працюєте
Valgrind.

У цих сценаріях ви можете надати абсолютний шлях як додаткове, останнє місце для
Valgrind для пошуку об’єктів налагодження за допомогою вказівки
--extra-debuginfo-path=/шлях/до/налагодження/об'єктів. Наведений шлях буде передувати
ім'я абсолютного шляху шуканого об'єкта. Наприклад, якщо Valgrind шукає
інформація про налагодження для /w/x/y/zz.so і --extra-debuginfo-path=/a/b/c вказано, буде
шукайте об’єкт налагодження на /a/b/c/w/x/y/zz.so.

Цей прапор потрібно вказати лише один раз. Якщо вказано кілька разів, тільки
шанується остання інстанція.

--debuginfo-server=ipaddr:порт [за замовчуванням: невизначених та невикористаний]
Це нова експериментальна функція, представлена ​​у версії 3.9.0.

У деяких сценаріях може бути зручно читати debuginfo з об’єктів, що зберігаються на a
різна машина. За допомогою цього прапорця Valgrind запитуватиме сервер debuginfo, на якому працює
ipaddr і прослуховує порт порту, якщо не може знайти об’єкт debuginfo в локальному
файлова система.

Сервер debuginfo повинен приймати TCP-з'єднання через порт порту. Сервер debuginfo є
міститься у вихідному файлі auxprogs/valgrind-di-server.c. Він буде служити тільки від
каталог, у якому він запущений. порт за замовчуванням має значення 1500 як на клієнті, так і на сервері if
не вказано.

Якщо Valgrind шукає інформацію про помилки для /w/x/y/zz.so за допомогою сервера debuginfo, він
видалить компоненти імені шляху і просто запитає zz.so на сервері. Це в
turn буде шукати відповідний об'єкт debuginfo лише у своєму поточному робочому каталозі.

Дані налагодження передаються невеликими фрагментами (8 КБ) за запитом Valgrind.
Кожен блок стискається за допомогою LZO для скорочення часу передачі. Реалізація має
був налаштований на найкращу продуктивність через одноступінчасте мережеве з’єднання 802.11g (WiFi).

Зверніть увагу, що перевіряє відповідність первинних і налагоджувальних об’єктів за допомогою CRC GNU debuglink
схеми, виконуються навіть при використанні сервера debuginfo. Щоб вимкнути таку перевірку,
вам також потрібно вказати --allow-mismatched-debuginfo=yes.

За замовчуванням система збирання Valgrind створить valgrind-di-server для цілі
платформа, що майже напевно не те, що ви хочете. Поки що нам не вдалося
дізнайтеся, як отримати automake/autoconf, щоб створити його для платформи збірки. Якщо хочеш
щоб використовувати його, вам доведеться перекомпілювати його вручну, використовуючи команду, показану вгорі
auxprogs/valgrind-di-server.c.

--allow-mismatched-debuginfo=ні|так [No]
Під час читання debuginfo з окремих об’єктів debuginfo, Valgrind за замовчуванням перевірить
щоб об’єкти main та debuginfo збігалися, використовуючи механізм посилання налагодження GNU. Це
гарантує, що він не читає debuginfo із застарілих об'єктів debuginfo, і
також гарантує, що Valgrind не може вийти з ладу в результаті невідповідності.

Цю перевірку можна скасувати за допомогою --allow-mismatched-debuginfo=yes. Це може бути
корисно, коли інформація про помилку та основні об'єкти не розділені належним чином. Будьте
будьте обережні при використанні цього: він вимикає всю перевірку узгодженості та Valgrind
спостерігається збій, коли об'єкти main і debuginfo не збігаються.

--подавлення= [за замовчуванням: $PREFIX/lib/valgrind/default.supp]
Визначає додатковий файл, з якого читати описи помилок для придушення. Ви можете
використовувати до 100 додаткових файлів придушення.

--gen-suppressions= [за замовчуванням: немає]
Коли встановлено значення так, Valgrind зупинятиметься після кожної показаної помилки та друкує рядок:

---- Придушення друку? --- [Повернення/N/n/Y/y/C/c] ----

пресування відмоваабо N відмова or n відмова, змушує Valgrind продовжувати виконання без друку a
придушення цієї помилки.

пресування Y відмова or y відмова змушує Valgrind написати придушення для цієї помилки. Ти можеш
потім виріжте та вставте його у файл придушення, якщо ви не хочете чути про це
помилка в майбутньому.

Коли встановлено значення всі, Valgrind буде друкувати придушення для кожної повідомленої помилки, без
запитуючи користувача.

Цей параметр особливо корисний для програм на C++, оскільки він друкує файли
придушення зі спотвореними іменами, якщо потрібно.

Зауважте, що надруковані сполучення є максимально конкретними. Можливо, ви захочете спільного
до подібних, додаючи символи підстановки до імен функцій та використовуючи рівень кадру
символи підстановки. Функції підстановки є потужними, але гнучкими, і з невеликою кількістю
ретельне редагування, ви зможете придушити ціле сімейство пов’язаних помилок
лише кілька придушень.

Іноді дві різні помилки придушуються одним і тим самим придушенням, і в цьому випадку
Valgrind виведе придушення більше одного разу, але вам потрібно лише одне
скопіюйте у свій файл придушення (але наявність кількох не викличе проблем). також,
назва придушення подається як ; назва ні
справді важливо, він використовується лише з -v параметр, який друкує всі використані придушення
записів.

--input-fd= [за замовчуванням: 0, stdin]
При використанні --gen-suppressions=так, Valgrind зупиниться, щоб прочитати введення з клавіатури
від вас, коли трапляється кожна помилка. За замовчуванням він читає зі стандартного введення (stdin),
що проблематично для програм, які закривають stdin. Цей параметр дозволяє вказати
альтернативний дескриптор файлу, з якого можна читати введені дані.

--dsymutil=ні|так [так]
Цей параметр актуальний лише під час запуску Valgrind на Mac OS X.

Mac OS X використовує схему зв’язування інформації відкладеного налагодження (debuginfo). Коли об’єкт
файли, що містять інформацію про помилки, пов’язані з файлом .dylib або виконуваним файлом, інформація про налагодження є
не скопійовано в остаточний файл. Натомість інформація про налагодження має бути пов’язана вручну за допомогою
запуск Dsymutil, системної утиліти, на виконуваному файлі або .dylib. The
отримана комбінована інформація налагодження розміщується в каталозі поряд із виконуваним файлом або
.dylib, але з розширенням .dSYM.

З --dsymutil=ні, Valgrind виявить випадки, коли каталог .dSYM є або
відсутній або присутній, але не відповідає пов’язаному виконуваному файлу або
.dylib, швидше за все, тому, що він застарів. У цих випадках Valgrind надрукує a
попереджувальне повідомлення, але не вживайте жодних дій.

З --dsymutil=так, у таких випадках Valgrind автоматично запускатиме dsymutil як
необхідно оновити інформацію про налагодження. Для всіх практичних цілей, якщо ви завжди
використання --dsymutil=так, то ніколи не буде потреби запускати dsymutil вручну або як частину
системи збірки ваших програм, оскільки Valgrind запустить її за потреби.

Valgrind не намагатиметься запустити dsymutil на будь-якому виконуваному файлі чи бібліотеці /usr/,
/ bin /, / sbin /, / opt /, /sw/, /System/, /Library/ або /Applications/, оскільки dsymutil
завжди зазнають невдачі в таких ситуаціях. Це не вдається, тому що інформація про налагодження для цього
попередньо встановлених системних компонентів немає ніде, а також тому, що було б
вимагають привілеїв запису в цих каталогах.

Будьте обережні при використанні --dsymutil=так, оскільки це спричинить вже існуючий .dSYM
каталоги, які будуть автоматично видалені та створені заново. Також зауважте, що дсимутил цілком
повільно, іноді надмірно.

--max-stackframe= [за замовчуванням: 2000000]
Максимальний розмір кадру стека. Якщо покажчик стека переміщується на більшу величину
тоді Valgrind вважатиме, що програма перемикається на інший стек.

Можливо, вам знадобиться використовувати цю опцію, якщо ваша програма має великі масиви, виділені стеком.
Valgrind відстежує вказівник стека вашої програми. Якщо воно зміниться більше ніж на
порогової суми, Valgrind припускає, що ваша програма перемикається на інший стек, і
Memcheck веде себе інакше, ніж при зміні покажчика стека, меншій за
поріг. Зазвичай ця евристика добре працює. Однак, якщо ваша програма виділяє великі
структур у стеку, ця евристика буде обдурена, а Memcheck згодом
повідомляти про велику кількість недійсних доступів до стека. Ця опція дозволяє змінити
поріг до іншого значення.

Ви повинні розглянути можливість використання цієї опції, лише якщо налагоджувальний вихід Valgrind спрямовує вас
зробити так. У цьому випадку він повідомить вам новий поріг, який ви повинні вказати.

Загалом, розподіляти великі структури на стеку — погана ідея, тому що можна
легко закінчиться місце в стеку, особливо в системах з обмеженою пам’яттю або які
очікувати підтримки великої кількості потоків, кожен з невеликим стеком, а також тому, що
перевірка помилок, що виконується Memcheck, є більш ефективною для даних, виділених у куче
ніж для даних, виділених стеком. Якщо вам потрібно скористатися цією опцією, ви можете це зробити
подумайте про те, щоб переписати свій код для розміщення в купі, а не в стеку.

--main-stacksize= [за замовчуванням: використання ток 'ліміт' значення]
Визначає розмір стека основного потоку.

Щоб спростити управління пам’яттю, Valgrind резервує весь необхідний простір для основної
стек потоку під час запуску. Це означає, що він повинен знати необхідний розмір стека
запуск

За замовчуванням Valgrind використовує поточне значення "ulimit" для розміру стека, або 16 МБ,
що нижче. У багатьох випадках це дає розмір стека в діапазоні від 8 до 16 МБ,
який майже ніколи не переповнюється для більшості програм.

Якщо вам потрібен більший загальний розмір стека, використовуйте --розмір основного стека щоб уточнити це. Тільки встановіть його
настільки високо, наскільки вам потрібно, оскільки ви резервуєте набагато більше місця, ніж вам потрібно (тобто сотні
мегабайт більше, ніж вам потрібно) обмежує розподільники пам'яті Valgrind і може
зменшити загальний обсяг пам’яті, який може використовувати Valgrind. Це лише насправді
значення на 32-розрядних машинах.

У Linux ви можете запросити стек розміром до 2 ГБ. Valgrind зупиниться на a
діагностичне повідомлення, якщо стек неможливо виділити.

--розмір основного стека впливає лише на розмір стека для початкового потоку програми. Це має
не впливає на розмір стеків ниток, оскільки Valgrind їх не виділяє.

Можливо, вам знадобиться використовувати обидва --розмір основного стека та --max-stackframe разом. це є
важливо це зрозуміти --розмір основного стека встановлює максимальний загальний розмір стека,
в той час як --max-stackframe визначає найбільший розмір будь-якого кадру стека. Ти будеш
треба відпрацювати --розмір основного стека цінність для себе (зазвичай, якщо ваш
додатки segfault). Але Valgrind підкаже вам, що потрібно --max-stackframe розмір,
якщо необхідно.

Як обговорюється далі в описі --max-stackframe, вимога до великого
стек є ознакою потенційних проблем з переносимістю. Краще всього розмістити
великі дані в пам'яті, що виділяється в купі.

--max-threads= [за замовчуванням: 500]
За замовчуванням Valgrind може обробляти до 500 потоків. Іноді це число також є
малий. Використовуйте цю опцію, щоб указати інший ліміт. Наприклад, --max-threads=3000.

MALLOC()-ПОВ’ЯЗАНО ВАРІАНТИ

Для інструментів, які використовують власну версію malloc (наприклад, Memcheck, Massif, Helgrind, DRD),
застосовуються наступні варіанти.

--alignment= [за замовчуванням: 8 or 16, залежно від on платформа]
За замовчуванням Valgrind's Танос, перерозподіл, тощо, повертають блок, початкова адреса якого є
8-байтове вирівнювання або 16-байтове вирівнювання (значення залежить від платформи і відповідає
платформи за замовчуванням). Цей параметр дозволяє вказати інше вирівнювання. The
надане значення має бути більше або дорівнювати значенню за замовчуванням, менше або дорівнювати
4096 і має бути степенем двійки.

--redzone-size= [за замовчуванням: залежить on інструмент]
Вальгрінда malloc, перерозподіл, тощо, додайте блоки заповнення до та після кожного блоку купи
виділені програмою, що запускається. Такі блоки заповнення називаються червоними зонами. The
Значення за замовчуванням для розміру червоної зони залежить від інструменту. Наприклад, Memcheck додає і
захищає мінімум 16 байт до і після кожного блоку, виділеного клієнтом.
Це дозволяє йому виявляти недорозвинення блоку або перевиконання до 16 байт.

Збільшення розміру червоної зони дає змогу виявляти перебіг на більших відстанях,
але збільшує обсяг пам'яті, використовуваної Valgrind. Зменшення розміру червоної зони буде
зменшує пам'ять, необхідну Valgrind, але також зменшує шанси на виявлення
перевищення/заниження, тому не рекомендується.

НЕКОМОН ВАРІАНТИ

Ці параметри застосовуються до всіх інструментів, оскільки вони впливають на деякі незрозумілі роботи Valgrind
ядро. Більшості людей не потрібно буде їх використовувати.

--smc-check= [за замовчуванням: не файл та цінності x86/amd64/s390x,
стек та цінності Інше арки]
Ця опція контролює визначення Valgrind коду, що самозмінюється. Якщо немає перевірки
Готово, коли програма виконує деякий код, потім перезаписує його новим кодом, і
виконує новий код, Valgrind продовжить виконувати переклади, які він зробив
старий код. Це, ймовірно, призведе до неправильної поведінки та/або збоїв.

Для "сучасної" архітектури - будь-чого, що не є x86, amd64 або s390x - за замовчуванням
is стек. Це пов’язано з тим, що правильна програма повинна виконувати чіткі дії для відновлення
Когерентність кешу DI після модифікації коду. Valgrind спостерігає та шанує таких
дії, в результаті чого код, що самомодифікується, прозоро обробляється з нулем
додаткові витрати.

Для x86, amd64 і s390x програмі не потрібно сповіщати апаратне забезпечення про
необхідна когерентна синхронізація DI. Тому за замовчуванням є не файл, яка охоплює
звичайний випадок генерування коду в анонімну (без підтримкою файлів) область mmap'd.

Чотири доступні налаштування мають наступне значення. Немає виявлення (ніхто),
виявити самомодифікований код у стеку (який використовується GCC для реалізації вкладеного
функції) (стек), виявляти скрізь код, що самомодифікується (всі), і виявити
код, що самозмінюється скрізь, окрім файлів зіставлення (не файл).

Біг з всі помітно сповільнить Valgrind. Біг з ніхто буде рідко
прискорити роботу, оскільки в більшості програм динамічно генерується дуже мало коду.
Команда VALGRIND_DISCARD_TRANSLATIONS запит клієнта є альтернативою --smc-check=все
та --smc-check=все-не-файл це вимагає більше зусиль програміста, але дозволяє Valgrind
щоб швидше запускати вашу програму, точно вказуючи їй, коли потрібен переклад
перероблений.

--smc-check=все-не-файл надає дешевшу, але обмежену версію
--smc-check=все. Він додає перевірки до будь-яких перекладів, які не походять з
відображення пам'яті з підтримкою файлів. Типові програми, які генерують код, наприклад JIT
у веб-браузерах генерувати код в анонімних областях mmaped, тоді як «фіксований» код
браузера завжди живе у файлових відображеннях. --smc-check=все-не-файл приймає
перевага цього спостереження, що обмежує накладні витрати на перевірку кодом, який є
ймовірно, буде створено JIT.

--read-inline-info= [за замовчуванням: побачити нижче]
Якщо ввімкнено, Valgrind читатиме інформацію про виклики вбудованих функцій із DWARF3
інформація про налагодження. Це уповільнює запуск Valgrind і змушує використовувати більше пам’яті (зазвичай для
кожен вбудований фрагмент коду, 6 слів і пробіл для назви функції), але це результат
у більш описових стеках. Для випуску 3.10.0 ця функція ввімкнена
за замовчуванням лише для цілей Linux, Android та Solaris і лише для інструментів
Memcheck, Helgrind і DRD. Ось приклад деяких трас стека з
--read-inline-info=ні:

==15380== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15380== на 0x80484EA: основний (inlinfo.c:6)
==15380==
==15380== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15380== на 0x8048550: fun_noninline (inlinfo.c:6)
==15380== за 0x804850E: основний (inlinfo.c:34)
==15380==
==15380== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15380== на 0x8048520: основний (inlinfo.c:6)

І тут такі ж помилки з --read-inline-info=так:

==15377== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15377== на 0x80484EA: fun_d (inlinfo.c:6)
==15377== від 0x80484EA: fun_c (inlinfo.c:14)
==15377== від 0x80484EA: fun_b (inlinfo.c:20)
==15377== від 0x80484EA: fun_a (inlinfo.c:26)
==15377== за 0x80484EA: основний (inlinfo.c:33)
==15377==
==15377== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15377== на 0x8048550: fun_d (inlinfo.c:6)
==15377== за 0x8048550: fun_noninline (inlinfo.c:41)
==15377== за 0x804850E: основний (inlinfo.c:34)
==15377==
==15377== Умовний стрибок або переміщення залежить від неініціалізованих значень
==15377== на 0x8048520: fun_d (inlinfo.c:6)
==15377== за 0x8048520: основний (inlinfo.c:35)

--read-var-info= [за замовчуванням: немає]
Якщо ввімкнено, Valgrind зчитуватиме інформацію про типи змінних і розташування
Інформація про налагодження DWARF3. Це значно уповільнює запуск Valgrind і змушує його використовувати
значно більше пам’яті, але для інструментів, які можуть скористатися нею (Memcheck,
Helgrind, DRD) це може призвести до більш точних повідомлень про помилки. Наприклад, ось
деякі стандартні помилки, видані Memcheck:

==15363== Неініціалізовані байти, знайдені під час запиту перевірки клієнта
==15363== на 0x80484A9: квакати (varinfo1.c:28)
==15363== за 0x8048544: main (varinfo1.c:55)
==15363== Адреса 0x80497f7 містить 7 байтів всередині символу даних "global_i2"
==15363==
==15363== Неініціалізовані байти, знайдені під час запиту перевірки клієнта
==15363== на 0x80484A9: квакати (varinfo1.c:28)
==15363== за 0x8048550: main (varinfo1.c:56)
==15363== Адреса 0xbea0d0cc знаходиться в стеку потоку 1
==15363== у кадрі №1, створеному main (varinfo1.c:45)

І тут такі ж помилки з --read-var-info=так:

==15370== Неініціалізовані байти, знайдені під час запиту перевірки клієнта
==15370== на 0x80484A9: квакати (varinfo1.c:28)
==15370== за 0x8048544: main (varinfo1.c:55)
==15370== Розташування 0x80497f7 становить 0 байт всередині global_i2[7],
==15370== глобальна змінна, оголошена в varinfo1.c:41
==15370==
==15370== Неініціалізовані байти, знайдені під час запиту перевірки клієнта
==15370== на 0x80484A9: квакати (varinfo1.c:28)
==15370== за 0x8048550: main (varinfo1.c:56)
==15370== Розташування 0xbeb4a0cc становить 0 байт всередині локальної змінної "local"
==15370== оголошено в varinfo1.c:46, у кадрі №1 потоку 1

--vgdb-poll= [за замовчуванням: 5000]
Як частина свого основного циклу, планувальник Valgrind проводить опитування, щоб перевірити, чи є певна активність
(наприклад, зовнішня команда або якийсь вхід з gdb) має оброблятися gdbserver.
Це опитування активності буде виконано після запуску заданої кількості базових блоків (або
трохи більше заданої кількості базових блоків). Це опитування досить дешеве, тому
значення за замовчуванням встановлено відносно низьким. Ви можете ще більше зменшити це значення, якщо vgdb
не можна використовувати системний виклик ptrace для переривання Valgrind, якщо всі потоки (більшість
час) заблоковано під час системного виклику.

--vgdb-shadow-registers=ні|так [за замовчуванням: немає]
Після активації gdbserver надаватиме GDB тіньові регістри Valgrind. З цим,
значення тіньових регістрів Valgrind можна перевірити або змінити за допомогою GDB.
Розкриття тіньових регістрів працює лише з GDB версії 7.1 або новішої.

--vgdb-prefix= [за замовчуванням: /tmp/vgdb-pipe]
Для зв’язку з gdb/vgdb gdbserver Valgrind створює 3 файли (2 іменованих FIFO
і файл спільної пам'яті mmap). Параметр префікса контролює каталог і префікс
для створення цих файлів.

--run-libc-freeres= [за замовчуванням: так]
Цей параметр актуальний лише під час запуску Valgrind на Linux.

Бібліотека GNU C (libc.so), який використовується всіма програмами, може виділити пам'ять для
власне використання. Зазвичай це не турбує звільнення цієї пам’яті, коли програма закінчується —
не було б сенсу, оскільки ядро ​​Linux повертає всі ресурси процесу, коли a
процес все одно завершується, тож це просто сповільнить роботу.

Автори glibc зрозуміли, що така поведінка викликає засоби перевірки витоків, такі як Valgrind,
щоб помилково повідомляти про витоки в glibc, коли перевірка витоку виконується на виході. Щоб уникнути
це, вони надали рутину називається __libc_freeres спеціально для випуску glibc
всю пам'ять, яку він виділив. Тому Memcheck намагається запуститися __libc_freeres на виході.

На жаль, у деяких дуже старих версіях glibc, __libc_freeres є достатньо
баггі, щоб викликати помилки сегментації. Особливо це було помітно на Red Hat 7.1.
Тому ця опція передбачена для того, щоб гальмувати біг __libc_freeres. Якщо ваш
Програма, здається, працює нормально на Valgrind, але ви можете виявити, що при виході з'являються помилки
--run-libc-freeres=ні виправляє це, хоча ціною можливого неправдивого повідомлення
витоки простору в libc.so.

--sim-hints=підказка1,підказка2,...
Передайте Valgrind різні підказки, які дещо змінюють змодельовану поведінку
нестандартні або небезпечні способи, можливо, щоб допомогти моделюванню дивних особливостей. За
за замовчуванням жодні підказки не включені. Використовуйте з обережністю! На даний момент відомі підказки:

· lax-ioctls: Будьте дуже повільними щодо обробки ioctl; Єдине припущення, що розмір
правильно. Не вимагає ініціалізації повного буфера під час запису.
Без цього використовувати деякі драйвери пристроїв з великою кількістю дивних ioctl
команди стають дуже стомлюючими.

· сумісний із запобіжником: Увімкнути спеціальну обробку для певних системних викликів, які можуть блокуватися
у файловій системі FUSE. Це може знадобитися під час запуску Valgrind на a
багатопотокова програма, яка використовує один потік для керування файловою системою FUSE і
інший потік для доступу до цієї файлової системи.

· увімкнути зовнішній: Увімкніть спеціальну магію, необхідну під час запуску програми
сам Valgrind.

· без внутрішнього префікса: Вимкнути друк префікса > перед кожним стандартним виведенням або stderr
вихідна лінія у внутрішньому Valgrind, що виконується зовнішнім Valgrind. Це корисно
під час виконання регресійних тестів Valgrind у зовнішній/внутрішній установці. Зауважте, що
префікс > завжди буде друкуватися перед внутрішніми рядками журналу налагодження.

· no-nptl-pthread-stackcache: Ця підказка актуальна лише під час запуску Valgrind
Linux

Бібліотека pthread GNU glibc (libpthread.so), який використовується програмами pthread,
підтримує кеш стеків pthread. Коли pthread завершується, використовувана пам'ять
для стека pthread і деяких структур даних, пов'язаних з локальним сховищем потоку, немає
завжди безпосередньо звільнений. Ця пам'ять зберігається в кеші (до певного розміру),
і повторно використовується, якщо запущено новий потік.

Цей кеш змушує інструмент helgrind повідомляти про хибнопозитивну гонку
помилки в цій кеш-пам'яті, оскільки helgrind не розуміє внутрішній glibc
примітиви синхронізації кешу. Отже, при використанні helgrind відключаємо кеш
допомагає уникнути хибнопозитивних умов гонки, зокрема при використанні нитки
локальні змінні зберігання (наприклад, змінні, що використовують __потік кваліфікаційний).

Під час використання інструменту memcheck вимкнення кешу гарантує використання пам’яті glibc
для обробки змінних __thread безпосередньо звільняється, коли потік завершується.

Примітка: Valgrind вимикає кеш, використовуючи деякі внутрішні знання стека glibc
реалізацію кешу та шляхом вивчення налагоджувальної інформації pthread
бібліотека. Таким чином, ця техніка є дещо крихкою і може працювати не для всіх glibc
версії. Це було успішно перевірено з різними версіями glibc (наприклад
2.11, 2.16, 2.18) на різних платформах.

· м'які двері: (Тільки для Solaris) Будьте дуже повільними щодо обробки системних викликів дверей
нерозпізнані дескриптори файлів дверей. Не вимагає повного буфера
ініціалізується під час запису. Без цього програми використовують libdoor(3LIB) функціональність
з повністю запатентованою семантикою може повідомляти про велику кількість помилкових спрацьовувань.

--fair-sched= [за замовчуванням: немає]
Команда -- справедливий графік параметр контролює механізм блокування, який Valgrind використовує для серіалізації
виконання потоку. Механізм блокування контролює спосіб розкладу ниток,
а різні налаштування дають різні компроміси між справедливістю та продуктивністю. Для
докладніше про схему серіалізації потоків Valgrind та її вплив на
продуктивність і планування потоків, див. Планування та багатопотокова продуктивність.

· Значення --fair-sched=так активує чесний планувальник. Словом, якщо кілька
потоки готові до запуску, потоки будуть заплановані по круговій системі.
Цей механізм доступний не на всіх платформах або версіях Linux. Якщо ні
доступний, корист --fair-sched=так призведе до завершення роботи Valgrind з помилкою.

Ви можете виявити, що це налаштування покращує загальну реагування, якщо ви запускаєте програму
інтерактивна багатопотокова програма, наприклад веб-браузер, на Valgrind.

· Значення --fair-sched=спробуйте активує справедливе планування, якщо доступне на платформі.
В іншому випадку він автоматично повернеться до --fair-sched=ні.

· Значення --fair-sched=ні активує планувальник, який не гарантує справедливості
між потоками, готовими до запуску, але загалом дає найвищу продуктивність.

--kernel-variant=варіант1,варіант2,...
Обробляти системні виклики та ioctl, які виникають із другорядних варіантів ядра за замовчуванням для
цю платформу. Це корисно для роботи на зламаних ядрах або з модулями ядра
які підтримують нестандартні ioctl, наприклад. Використовуйте з обережністю. Якщо ви цього не зробите
зрозумійте, що робить ця опція, тоді вона вам майже напевно не знадобиться. Наразі
відомі варіанти:

· bproc: підтримати sys_broc системний виклик на x86. Це для роботи на BProc,
який є незначним варіантом стандартного Linux, який іноді використовується для створення
кластери.

· android-no-hw-tls: деякі версії емулятора Android для ARM не надають a
апаратний реєстр TLS (локальний стан потоку), і Valgrind виходить з ладу під час запуску. Використовуйте
цей варіант для вибору програмної підтримки TLS.

· android-gpu-sgx5xx: використовуйте це для підтримки роботи з власними ioctl для
Графічні процесори серії PowerVR SGX 5XX на пристроях Android. Якщо цього не вибрати, немає
спричиняє проблеми зі стабільністю, але може спричинити повідомлення Memcheck про помилкові помилки після
програма виконує специфічні для графічного процесора ioctl.

· android-gpu-adreno3xx: аналогічно, використовуйте це для підтримки роботи з проприетарними
ioctls для графічних процесорів серії Qualcomm Adreno 3XX на пристроях Android.

--merge-recursive-frames= [за замовчуванням: 0]
Деякі рекурсивні алгоритми, наприклад, збалансовані реалізації двійкового дерева, створюють
багато різних трас стека, кожна з яких містить цикли викликів. Цикл визначається як
два однакові значення програмного лічильника, розділені нулем або більше іншим програмним лічильником
цінності. Тоді Valgrind може використовувати багато пам’яті для зберігання всіх цих трас стека. Це
погане використання пам'яті, враховуючи, що такі стеки містять повторювані нецікаві
рекурсивні виклики замість більш цікавої інформації, наприклад функції, яка має
ініціював рекурсивний виклик.

Опція --merge-recursive-frames= доручає Valgrind виявити та об’єднати
цикли рекурсивного виклику, що мають розмір до рами. Коли такий цикл є
Виявлено, Valgrind записує цикл у стеку як унікальний лічильник програми.

Значення 0 (за замовчуванням) не викликає рекурсивного злиття викликів. Значення 1 спричинить
стек слідів простих рекурсивних алгоритмів (наприклад, факторна реалізація)
підлягати згортанню. Для згортання створених трас стека зазвичай потрібно значення 2
за допомогою рекурсивних алгоритмів, таких як двійкові дерева, швидке сортування тощо. Можуть бути вищі значення
необхідний для більш складних рекурсивних алгоритмів.

Примітка: рекурсивні виклики виявляються шляхом аналізу значень програмного лічильника. Вони не
виявляється, дивлячись на назви функцій.

--кількість-transtab-sectors= [за замовчуванням: 6 та цінності Android платформи, 16 та цінності всі інші]
Valgrind перекладає та інструментує машинний код вашої програми невеликими фрагментами
(основні блоки). Переклади зберігаються в кеші перекладів, який розділений
на ряд розділів (секторів). Якщо кеш заповнений, сектор, що містить файл
найстаріші переклади спорожняються та використовуються повторно. Якщо ці старі переклади знову знадобляться,
Valgrind повинен повторно перекласти та переінструментувати відповідний машинний код, який є
дорогий. Якщо робочий набір програми «виконані інструкції» великий, то збільшується
кількість секторів може покращити продуктивність за рахунок зменшення кількості
необхідні повторні переклади. Сектори виділяються на вимогу. Після виділення сектор може
ніколи не звільняється, і займає значний простір, залежно від інструменту та вартості
of --avg-transtab-entry-size (близько 40 МБ на сектор для Memcheck). Скористайтеся опцією
--stats=так щоб отримати точну інформацію про пам'ять, яку використовує сектор і
розподіл і переробка секторів.

--avg-transtab-entry-size= [за замовчуванням: 0, сенс використання інструмент за умови за замовчуванням]
Середній розмір перекладеного базового блоку. Цей середній розмір використовується для визначення розмірів
розмір сектора. Кожен інструмент надає значення за замовчуванням. Якщо це значення за замовчуванням
занадто малий, сектори перекладу будуть заповнені занадто швидко. Якщо це за замовчуванням
значення занадто велике, значна частина пам'яті сектора перекладів буде невикористаною.
Зауважте, що середній розмір перекладу базового блоку залежить від інструменту та може
залежать від параметрів інструменту. Наприклад, опція memcheck --track-origins=так збільшується
розмір основного блоку перекладів. Використовуйте --avg-transtab-entry-size налаштувати
розмір секторів, щоб отримати пам'ять або уникнути занадто великої кількості повторних перекладів.

--aspace-minaddr= [за замовчуванням: залежить on платформа]
Щоб уникнути потенційних конфліктів з деякими системними бібліотеками, Valgrind не використовує файл
адресний простір нижче --aspace-minaaddr значення, зберігаючи його зарезервованим на випадок бібліотеки
спеціально запитує пам'ять у цьому регіоні. Отже, вгадується якесь «песимістичне» значення
від Valgrind залежно від платформи. У Linux за замовчуванням Valgrind уникає використання файлу
перші 64 МБ, навіть якщо зазвичай немає конфлікту в цій повній зоні. Ви можете використовувати
варіант --aspace-minaaddr щоб отримати користь від програми, яка потребує пам’яті
більше цієї нижчої пам’яті. З іншого боку, якщо ви зіткнетеся з конфліктом, він посилюється
Значення aspace-minaddr може вирішити цю проблему. Конфлікти зазвичай проявляються з
помилки mmap у нижньому діапазоні адресного простору. Вказана адреса має бути сторінкою
вирівняний і має бути рівним або більшим 0x1000 (4 КБ). Щоб знайти значення за замовчуванням на вашому
платформі, зробіть щось на кшталт valgrind -d -d date 2>&1 | grep -i minaddr. Цінності
Відомо, що значення нижче 0x10000 (64 КБ) створюють проблеми в деяких дистрибутивах.

--valgrind-stacksize= [за замовчуванням: 1 МБ]
Для кожного потоку Valgrind потрібен власний «приватний» стек. Розмір за замовчуванням для них
стеки значною мірою мають розміри, і цього має бути достатньо в більшості випадків. У разі
розмір надто малий, Valgrind буде segfault. Перед segfaulting може бути попередження
виробляється Valgrind при наближенні до межі.

Скористайтеся опцією --valgrind-розмір стеку якщо таке (малоймовірне) попередження зроблено, або
Valgrind помирає через порушення сегментації. Такі порушення сегментації були
спостерігається під час розбирання величезних символів C++.

Якщо ваша програма використовує багато потоків і потребує багато пам’яті, ви можете отримати трохи
пам’яті, зменшуючи розмір цих стеків Valgrind за допомогою параметра
--valgrind-розмір стеку.

--show-emwarns= [за замовчуванням: немає]
Якщо ввімкнено, Valgrind у певних випадках видаватиме попередження про емуляцію ЦП.
Зазвичай це нецікаво.

--require-text-symbol=:sonnamepatt:fnnamepatt
Коли спільний об’єкт, чиє ім’я співпадає sonamepatt завантажується в процес,
перевірте всі текстові символи, які він експортує. Якщо жоден із них не збігається fnnamepatt, надрукувати ан
повідомлення про помилку та припинити виконання. Це дає можливість переконатися, що біг виконується
не продовжувати, якщо даний спільний об'єкт не містить конкретну назву функції.

обидві sonamepatt та fnnamepatt можна написати за допомогою звичайного ? та * символи підстановки. Для
приклад: ":*libc.so*:foo?bar". Для розділення можна використовувати символи, відмінні від двокрапки
два візерунки. Важливо лише, щоб перший символ і роздільник
характер однаковий. Наприклад, наведений вище приклад також можна було б написати
"Q*libc.so*Qfoo?bar". Кілька
--require-text-symbol прапори дозволені, і в цьому випадку спільні об’єкти, які завантажуються
у процесі буде перевірено щодо всіх них.

Метою цього є підтримка надійного використання розмічених бібліотек. Наприклад,
припустимо, що у нас є версія GCC libgomp.so який був позначений
анотації для підтримки Helgrind. Завантажити неправильне надто легко і заплутано,
без коментарів libgomp.so в додаток. Отже, ідея така: додати текстовий символ в
розмічена бібліотека, наприклад annotated_for_helgrind_3_6, а потім дайте прапор
--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 так що коли libgomp.so
завантажується, Valgrind сканує свою таблицю символів, і якщо символ відсутній, виконується
перервано, а не продовжувати мовчки з нерозміченою бібліотекою. Зверніть увагу, що ви
слід помістити весь прапор у лапки, щоб зупинити розширення оболонок вгору * та ?
символи підстановки.

--sonname-synonyms=syn1=шаблон1,syn2=шаблон2,...
Коли спільна бібліотека завантажується, Valgrind перевіряє функції в бібліотеці, які
необхідно замінити або загорнути. Наприклад, Memcheck замінює всі пов’язані з malloc
функції (malloc, free, calloc, ...) зі своїми версіями. Такі заміни є
виконується за замовчуванням лише в спільних бібліотеках, чиє ім’я співпадає з попередньо визначеним ім’ям
візерунок (напр libc.so* на Linux). За замовчуванням не виконується заміна для статичного
пов’язану бібліотеку або для альтернативних бібліотек, таких як tcmalloc. У деяких випадках
заміни дозволяють --sonname-синоніми вказати один додатковий синонімічний шаблон, даючи
гнучкість при заміні.

Наразі ця гнучкість дозволена лише для пов’язаних з malloc функцій, використовуючи
синонім сомаллок. Цей синонім можна використовувати для всіх інструментів, які виконують стандартну заміну
пов'язаних з malloc функцій (наприклад, memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Альтернативна бібліотека malloc: замінити пов'язані з malloc функції альтернативною
бібліотека з soname mymalloclib.so, дати варіант
--sonname-synonyms=somalloc=mymalloclib.so. Шаблон можна використовувати для відповідності кількох
бібліотеки сонамен. Наприклад, --sonname-synonyms=somalloc=*tcmalloc* буде відповідати
назва всіх варіантів бібліотеки tcmalloc (рідний, налагоджувальний, профільований, ...
варіанти tcmalloc).

Примітка: soname спільної бібліотеки elf можна отримати за допомогою readelf
утиліта

· Заміни в статично зв'язаній бібліотеці здійснюються за допомогою NONE рисунок.
Наприклад, якщо ви посилаєте з libtcmalloc.a, memcheck буде належним чином працювати, коли ви
дайте можливість --sonname-synonyms=somalloc=НІ. Зверніть увагу, що шаблон NONE буде
відповідати основному виконуваному файлу та будь-якій спільній бібліотеці, яка не має soname.

· Щоб запустити збірку Firefox за замовчуванням для Linux, у якій JEMalloc пов’язано з
основний виконуваний файл, використання --sonname-synonyms=somalloc=НІ.

ВІДМОВЛЕННЯ VALGRIND ВАРІАНТИ

Є також деякі варіанти налагодження самого Valgrind. Вам не потрібно їх використовувати
в нормальному руслі речей. Якщо ви хочете побачити список, скористайтеся --help-debug варіант.

MEMCHECK ВАРІАНТИ

--leak-check= [за замовчуванням: резюме]
Якщо ввімкнено, шукайте витоки пам’яті після завершення роботи клієнтської програми. Якщо встановлено на
Підсумок, там зазначено, скільки витоків відбулося. Якщо встановлено на Повний or так, кожен витік окремо
буде показано детально та/або зараховано як помилка, як зазначено в параметрах
--show-leak-kinds та --помилки-для-видів витоку.

--leak-resolution= [за замовчуванням: високий]
Виконуючи перевірку на витоки, визначає, наскільки Memcheck готовий розглядати різне
зворотні траси повинні бути однаковими для цілей об’єднання кількох витоків в один
звіт про витік. Коли встановлено на низький, лише перші два записи мають відповідати. Коли мед, чотири
записи повинні збігатися. Коли висока, усі записи мають збігатися.

Для жорсткого налагодження витоків ви, ймовірно, захочете скористатися --leak-resolution=висока разом
з --кількість абонентів=40 або якась така велика кількість.

Зауважте, що --роздільна здатність витоку налаштування не впливає на здатність Memcheck знаходити
витоків. Це лише змінює спосіб представлення результатів.

--show-leak-kinds= [за замовчуванням: визначений, можливий]
Визначає види витоку, які відображаються в a Повний пошук витоків одним із таких способів:

· розділений комами список з одного або кількох визначений непрямий це можливо доступний.

· всі вказати комплектацію (всі види витоку). Це еквівалентно
--show-leak-kinds=визначений,непрямий,можливий,досяжний.

· ніхто для порожнього набору.

--errors-for-leak-kinds= [за замовчуванням: визначений, можливий]
Визначає види витоку, які вважатимуться помилками в a Повний пошук витоку. The is
зазначено аналогічно --show-leak-kinds

--leak-check-euristics= [за замовчуванням: всі]
Визначає набір евристик перевірки витоків, які будуть використовуватися під час пошуку витоків. The
евристичні засоби контролюють, якими внутрішніми вказівниками блок буде вважатися
доступний. Евристичний набір задається одним із наступних способів:

· розділений комами список з одного або кількох stdstring довжина64 новий масив
множинна спадковість.

· всі щоб активувати повний набір евристик. Це еквівалентно
--leak-check-euristics=stdstring,length64,newarray,multipleinheritance.

· ніхто для порожнього набору.

Зауважте, що ці евристики залежать від компонування об’єктів, створених
Компілятор C++. Вони були протестовані з деякими версіями gcc (наприклад, 4.4 і 4.7). Вони
може не працювати належним чином з іншими компіляторами C++.

--show-reachable= , --show-possibly-lost=
Ці параметри надають альтернативний спосіб вказати типи витоку для відображення:

· --show-reachable=ні --show-possibly-lost=так еквівалентна
--show-leak-kinds=визначений,можливий.

· --show-reachable=ні --show-possibly-lost=ні еквівалентна
--show-leak-kinds=визначено.

· --show-reachable=так еквівалентна --show-leak-kinds=усі.

Зверніть увагу, що --show-possibly-lost=ні не має ефекту, якщо --show-reachable=так вказано.

--undef-value-errors= [за замовчуванням: так]
Контролює, чи повідомляє Memcheck про використання помилок невизначених значень. Встановіть для цього значення немає if
ви не хочете бачити помилки невизначеного значення. Це також має побічний ефект перевищення швидкості
трохи підвищити Memcheck.

--track-origins= [за замовчуванням: немає]
Контролює, чи відстежує Memcheck походження неініціалізованих значень. За замовчуванням це
ні, що означає, що хоча він може сказати вам, що неініціалізоване значення є
будучи небезпечним способом, він не може сказати вам, звідки надійшло неініціалізоване значення
від Це часто ускладнює виявлення кореневої проблеми.

Коли встановлено значення так, Memcheck відстежує походження всіх неініціалізованих значень.
Потім, коли повідомляється про помилку неініціалізованого значення, Memcheck спробує показати
походження вартості. Початком координат може бути одне з наступних чотирьох місць: блок купи,
розподіл стека, запит клієнта або інші інші джерела (наприклад, виклик до
битий).

Для неініціалізованих значень, що походять із блоку купи, Memcheck показує, де знаходиться блок
було виділено. Для неініціалізованих значень, що походять із розподілу стека, Memcheck
може сказати вам, яка функція призначила значення, але не більше того - зазвичай це
показує вихідне розташування відкриває дужки функції. Тож ти повинен
уважно перевірте, чи всі локальні змінні функції ініціалізовані належним чином.

Накладні витрати на продуктивність: відстеження походження коштує дорого. Це вдвічі зменшує швидкість Memcheck і
збільшує використання пам’яті мінімум на 100 МБ, а можливо і більше. Проте може
різко скоротити зусилля, необхідні для виявлення першопричини неініціалізації
значення помилок, і тому часто виграє продуктивність програміста, незважаючи на те, що він працює більше
повільно.

Точність: Memcheck досить точно відстежує походження. Щоб уникнути дуже великого простору та часу
накладні витрати, зроблено деякі наближення. Це можливо, хоча й малоймовірно
Memcheck повідомить про неправильне походження або не зможе визначити будь-яке походження.

Зверніть увагу, що комбінація --track-origins=так та --undef-value-errors=ні is
безглуздий. Memcheck перевіряє та відхиляє цю комбінацію під час запуску.

--partial-loads-ok= [за замовчуванням: так]
Керує тим, як Memcheck обробляє 32-, 64-, 128- і 256-бітові навантаження з природним вирівнюванням від
адреси, для яких одні байти є адресними, а інші ні. Коли так, такий
завантаження не викликають помилку адреси. Натомість завантажені байти, які походять із незаконних
адреси позначаються як неініціалізовані, а ті, що відповідають юридичним адресам, є
обробляється звичайним способом.

Коли немає, завантаження з частково недійсних адрес розглядаються так само, як і завантаження з
повністю недійсні адреси: видається помилка illegal-address, і в результаті
байти позначаються як ініціалізовані.

Зауважте, що код, який веде себе таким чином, порушує стандарти ISO C/C++,
і слід вважати зламаною. Якщо це взагалі можливо, такий код слід виправити.

--expensive-definedness-checks= [за замовчуванням: немає]
Контролює, чи повинен Memcheck використовувати більш точні, але й дорожчі (час
споживання) алгоритмів під час перевірки визначеності значення. Налаштування за замовчуванням
не робити цього, і зазвичай цього достатньо. Однак для високо оптимізованого коду
valgrind іноді може неправильно скаржитися. Виклик valgrind с
--expensive-definedness-checks=так допомагає, але коштує продуктивності. Час виконання
спостерігається деградація на 25%, але додаткові витрати багато в чому залежать від
додаток під рукою.

--keep-stacktraces=alloc|безкоштовно|alloc-and-free|alloc-then-free|немає [за замовчуванням:
розподілити та безкоштовно]
Визначає, які стеки слід зберігати для блоків із malloc та/або звільненими.

З alloc-to-free, трасування стека записується під час виділення та пов’язується
з блоком. Коли блок звільняється, записується друга траса стека, і це
замінює трасування стека розподілу. Як результат, будь-які помилки "використання після безкоштовного".
цьому блоці можна показувати лише стек трасування місця звільнення блоку.

З розподілити та безкоштовно, трасування стеку як виділення, так і звільнення для блоку
зберігаються. Тому помилка "використовувати після безкоштовного" показуватиме обидві, що може призвести до помилки
легше діагностувати. У порівнянні з alloc-to-free, цей параметр дещо збільшується
Використання пам'яті Valgrind як блок містить два посилання замість одного.

З розподілити, записується (і повідомляється) лише трасування стека розподілу. З безкоштовно,
записується (і повідомляється) лише трасування стека звільнення. Ці значення дещо
зменшити використання пам'яті та процесора Valgrind. Вони можуть бути корисними залежно від помилки
типи, які ви шукаєте, і рівень деталізації, необхідний для їх аналізу. Для
Наприклад, якщо вас цікавлять лише помилки витоку пам'яті, достатньо зробити запис
трасування стека розподілу.

З ніхто, для операцій malloc і free не записуються сліди стека. Якщо ти
програма виділяє багато блоків і/або виділяє/звільняє з багатьох різних стеків
слідів, це може значно зменшити потрібний процесор та/або пам’ять. Звичайно, небагато
деталі будуть повідомлятися про помилки, пов’язані з блоками купи.

Зауважте, що після запису трасування стека Valgrind зберігає трасування стека в пам’яті
навіть якщо на нього не посилається жодний блок. Деякі програми (наприклад, рекурсивні
алгоритмів) може генерувати величезну кількість трас стека. Якщо Valgrind використовує занадто багато
за таких обставин ви можете зменшити необхідну пам’ять за допомогою параметрів
--keep-stacktraces та/або за допомогою меншого значення для опції --число абонентів.

--freelist-vol= [за замовчуванням: 20000000]
Коли клієнтська програма звільняє пам’ять, використовуючи безкоштовно (на C) або видалити (C++) цю пам'ять
не надається негайно для перерозподілу. Натомість позначено
недоступні і поміщені в чергу звільнених блоків. Мета полягає в тому, щоб відкласти до тих пір
можливий момент, коли звільнена пам'ять повертається в обіг. Це
збільшує ймовірність того, що Memcheck зможе виявити недійсні доступи до блоків
протягом певного значного періоду часу після їх звільнення.

Цей параметр визначає максимальний загальний розмір блоків у черзі в байтах.
Значення за замовчуванням становить двадцять мільйонів байт. Збільшення цього збільшує загальну суму
пам’яті, яку використовує Memcheck, але може виявити недійсне використання звільнених блоків, які б
інакше залишиться непоміченим.

--freelist-big-blocks= [за замовчуванням: 1000000]
Роблячи блоки з черги звільнених блоків доступними для перерозподілу,
Memcheck буде в пріоритеті повторно циркулювати блоки з розміром, більшим або рівним
--freelist-big-blocks. Це гарантує, що звільнення великих блоків (зокрема, звільнення
блоків більше ніж --freelist-vol) не відразу призводить до повторної циркуляції
всі (або багато) маленьких блоків у вільному списку. Іншими словами, цей варіант
навіть збільшує ймовірність виявлення звисаючих покажчиків для «невеликих» блоків
коли великі блоки звільняються.

Встановлення значення 0 означає, що всі блоки повторно циркулюють у порядку FIFO.

--обхідний шлях-gcc296-bugs= [за замовчуванням: немає]
Якщо ввімкнено, припустимо, що виконується читання та запис на деяку невелику відстань нижче вказівника стека
пов'язані з помилками в GCC 2.96 і не повідомляє про них. «Мала відстань» — 256
байтів за замовчуванням. Зверніть увагу, що GCC 2.96 є компілятором за замовчуванням у деяких стародавніх Linux
дистрибутивів (RedHat 7.X), тому вам може знадобитися використовувати цю опцію. Не використовуйте його, якщо
вам не потрібно, оскільки це може призвести до того, що реальні помилки будуть пропущені. Краща альтернатива
полягає у використанні новішої GCC, в якій цю помилку виправлено.

Вам також може знадобитися використовувати цю опцію під час роботи з GCC 3.X або 4.X на 32-розрядних версіях
PowerPC Linux. Це тому, що GCC генерує код, який час від часу звертається нижче
покажчик стека, особливо для перетворення з плаваючою комою в/з цілого числа. Це
порушує 32-розрядну специфікацію PowerPC ELF, яка не передбачає
місця під вказівником стека, щоб бути доступними.

--show-mismatched-frees= [за замовчуванням: так]
Якщо ввімкнено, Memcheck перевіряє, чи звільнено блоки купи за допомогою функції, яка
відповідає функції розподілу. Тобто очікує безкоштовно використовуватися для звільнення
блоки, виділені за допомогою Танос, видаляти для блоків, виділених new та видалити [] та цінності
блоки, виділені за допомогою новий[]. Якщо виявлено невідповідність, повідомляється про помилку. Це в
Загалом важливо, оскільки в деяких середовищах звільнення з невідповідною функцією
може викликати збої.

Проте існує сценарій, коли таких невідповідностей не уникнути. Саме тоді
користувач надає реалізації new/новий[] той дзвінок Танос і видаляти/видалити []
той дзвінок безкоштовно, і ці функції асиметрично вбудовані. Наприклад, уявіть
Що видалити [] є вбудованим але новий[] не. В результаті Memcheck «бачить» все
видалити [] дзвінки як прямі дзвінки до безкоштовно, навіть якщо джерело програми не містить
невідповідні дзвінки.

Це викликає багато заплутаних і невідповідних звітів про помилки.
--show-mismatched-frees=ні вимикає ці перевірки. Як правило, це не рекомендується
вимкніть їх, однак, тому що в результаті ви можете пропустити реальні помилки.

--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
Будь-які діапазони, перераховані в цьому параметрі (і можна вказати кілька діапазонів, розділених символами
коми) буде ігноруватися перевіркою адресності Memcheck.

--malloc-fill=
Заповнює блоки, виділені malloc, new тощо, але не calloc, зазначеним
байт. Це може бути корисно під час спроби усунути незрозумілі проблеми пошкодження пам’яті.
Виділена область все ще розглядається Memcheck як невизначена - лише ця опція
впливає на його зміст. Зауважте, що --malloc-fill не впливає на блок пам’яті, коли
він використовується як аргумент клієнтських запитів VALGRIND_MEMPOOL_ALLOC або
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill=
Заповнює блоки, звільнені за допомогою free, delete тощо, вказаним значенням байта. Це може бути
корисно під час спроби усунути незрозумілі проблеми пошкодження пам'яті. Звільнена площа є
досі розглядається Memcheck як неприпустимий для доступу - цей параметр впливає лише на його
зміст. Зауважте, що --безкоштовне заповнення не впливає на блок пам'яті, коли він використовується як
аргумент для клієнтських запитів VALGRIND_MEMPOOL_FREE або VALGRIND_FREELIKE_BLOCK.

КЕГРІНД ВАРІАНТИ

--I1= , , розмір>
Вкажіть розмір, асоціативність і розмір рядка кешу інструкцій рівня 1.

--D1= , , розмір>
Вкажіть розмір, асоціативність і розмір рядка кешу даних рівня 1.

--LL= , , розмір>
Вкажіть розмір, асоціативність і розмір рядка кешу останнього рівня.

--cache-sim=ні|так [так]
Вмикає або вимикає збір доступу до кешу та підрахунку промахів.

--branch-sim=ні|так [No]
Вмикає або вимикає збір інструкцій гілки та підрахунку помилок. За
за замовчуванням це вимкнено, оскільки це сповільнює Cachegrind приблизно на 25%. Зауважте, що
ви не можете вказати --cache-sim=ні та --branch-sim=ні разом, як це залишило б
Cachegrind без інформації для збору.

--cachegrind-out-file=
Запишіть дані профілю у файл, а не у вихідний файл за замовчуванням,
cachegrind.out. . The %p та %q Специфікатори формату можна використовувати для вбудовування процесу
Ідентифікатор та/або вміст змінної середовища в імені, як у випадку з
основний варіант --файл журналу.

КАЛЛГРІНД ВАРІАНТИ

--callgrind-out-file=
Запишіть дані профілю у файл, а не у вихідний файл за замовчуванням,
callgrind.out. . The %p та %q Специфікатори формату можна використовувати для вбудовування процесу
Ідентифікатор та/або вміст змінної середовища в імені, як у випадку з
основний варіант --файл журналу. Коли створюється кілька дампов, ім’я файлу змінюється
далі; Дивись нижче.

--dump-line= [за замовчуванням: так]
Це вказує, що підрахунок подій має виконуватися з деталізації вихідного рядка.
Це дозволяє анотувати джерела для джерел, які скомпільовано з інформацією про налагодження
(-g).

--dump-instr= [за замовчуванням: немає]
Це вказує, що підрахунок подій має виконуватися з деталізації для кожної інструкції.
Це дозволяє робити анотації коду збірки. Наразі результати можна лише відобразити
від KCachegrind.

--compress-strings= [за замовчуванням: так]
Цей параметр впливає на вихідний формат даних профілю. У ньому вказується чи
рядки (імена файлів і функцій) мають бути ідентифіковані цифрами. Це зменшує
файл, але ускладнює його читання для людей (що не рекомендується в жодному
випадок).

--compress-pos= [за замовчуванням: так]
Цей параметр впливає на вихідний формат даних профілю. У ньому вказується чи
числові позиції завжди вказуються як абсолютні значення або допускаються
відносно попередніх чисел. Це зменшує розмір файлу.

--combine-dumps= [за замовчуванням: немає]
Якщо ввімкнено, коли має бути створено кілька частин даних профілю, ці частини є
додається до того самого вихідного файлу. Не рекомендовано.

--dump-every-bb= [за замовчуванням: 0, ніколи]
Кожне скидати дані профілю вважати базові блоки. Чи потрібен дамп, лише перевіряється
коли запущено внутрішній планувальник Valgrind. Тому мінімальний параметр корисний
приблизно 100000. Лічильник є 64-бітним значенням, щоб зробити можливими тривалі періоди дампу.

--dump-before=
Дамп при вході функція.

--zero-before=
Обнуляйте всі витрати при вході функція.

--dump-after=
Звали при виході функція.

--instr-atstart= [за замовчуванням: так]
Укажіть, чи хочете ви, щоб Callgrind розпочинав моделювання та профілювання з самого початку
Програма. Якщо встановлено значення ні, Callgrind не зможе збирати будь-яку інформацію,
включаючи дзвінки, але він матиме щонайбільше сповільнення близько 4, що є мінімумом
Valgrind над головою. Інструментарію можна ввімкнути в інтерактивному режимі за допомогою callgrind_control
-я на.

Зауважте, що результуючий графік викликів, швидше за все, не міститиме основний, але буде
містять усі функції, які виконуються після ввімкнення інструментарію. Інструментальне обладнання
також можна програмно ввімкнути/вимкнути. Дивіться файл включення Callgrind callgrind.h
для макросу, який потрібно використовувати у своєму вихідному коді.

Для симуляції кешу результати будуть менш точними при ввімкненні приладів
пізніше під час виконання програми, оскільки в цей момент симулятор запускається з порожнім кешем.
Щоб усунути цю помилку, увімкніть збір подій пізніше.

--collect-atstart= [за замовчуванням: так]
Укажіть, чи ввімкнено збір подій на початку запуску профілю.

Щоб переглянути лише частини вашої програми, у вас є дві можливості:

1. Обнуляйте лічильники подій перед входом до частини програми, яку потрібно профільувати, і викачуйте
подія повертається до файлу після виходу з цієї частини програми.

2. Увімкніть/вимкніть стан збору за потребою, щоб бачити лише лічильники подій
перебуваючи всередині частини програми, яку потрібно профільувати.

Другий варіант можна використовувати, якщо частина програми, яку потрібно профільувати, називається багато
разів. Варіант 1, тобто створення великої кількості дампів, тут не практичний.

Стан колекції можна перемикати при вході та виході з даної функції за допомогою параметра
--перемкнути-збирати. Якщо ви використовуєте цю опцію, стан збору має бути вимкнено на
початок. Зверніть увагу, що специфікація --перемкнути-збирати неявно задає
--collect-state=ні.

Стан збору можна також змінити, вставивши запит клієнта
CALLGRIND_TOGGLE_COLLECT ; на потрібних кодових позиціях.

--toggle-collect=
Увімкніть збір під час входу/виходу з функція.

--collect-jumps= [за замовчуванням: немає]
Це визначає, чи потрібно збирати інформацію для (умовних) стрибків. Як
вище, callgrind_annotate наразі не може показати вам дані. Ви повинні використовувати
KCachegrind, щоб отримати стрілки переходу в анотованому коді.

--collect-systime= [за замовчуванням: немає]
Це визначає, чи потрібно збирати інформацію про час системних викликів.

--collect-bus= [за замовчуванням: немає]
Це визначає, чи потрібно збирати кількість виконаних подій глобальної шини.
Для цих подій використовується тип події «Ge».

--cache-sim= [за замовчуванням: немає]
Укажіть, чи бажаєте ви виконати моделювання повного кешу. За замовчуванням читається лише інструкція
доступи будуть зараховані ("Ir"). За допомогою моделювання кешу є додаткові лічильники подій
увімкнено: промахи в кешу під час читання інструкцій ("I1mr"/"ILmr"), доступ до зчитування даних ("Dr")
і пов'язані промахи кешу ("D1mr"/"DLmr"), доступ до запису даних ("Dw") і пов'язаний кеш
промахи ("D1mw"/"DLmw"). Для отримання додаткової інформації див. Cachegrind: кеш і розгалуження-
профайлер прогнозів.

--branch-sim= [за замовчуванням: немає]
Укажіть, чи бажаєте ви виконувати моделювання передбачення гілок. Далі є лічильники подій
увімкнено: кількість виконаних умовних розгалужень і пов’язаних промахів предиктора
("Bc"/"Bcm"), виконані непрямі стрибки та пов'язані з ними промахи предиктора адреси переходу
(«Бі»/«Бім»).

ХЕЛЬГРІНД ВАРІАНТИ

--free-is-write=ні|так [за замовчуванням: немає]
Коли ввімкнено (не за замовчуванням), Helgrind розглядає звільнення пам’яті купи так, ніби
пам'ять була записана безпосередньо перед вільною. Це виявляє раси, де пам’ять
посилається одним потоком і звільняється іншим, але не спостерігається
подія синхронізації, щоб переконатися, що посилання відбувається перед безкоштовним.

Ця функція є новою у Valgrind 3.7.0 і вважається експериментальною. це є
не ввімкнено за замовчуванням, оскільки його взаємодія з користувацькими розподільниками пам’яті не є
на даний момент добре зрозумілий. Відгуки користувачів вітаються.

--track-lockorders=ні|так [за замовчуванням: так]
Якщо ввімкнено (за замовчуванням), Helgrind виконує перевірку послідовності порядку блокування. Для
деякі помилкові програми можуть стати великою кількістю помилок порядку блокування
дратує, особливо якщо вас цікавлять лише помилки перегонів. Тому ви можете
корисно вимкнути перевірку порядку блокування.

--history-level=none|приблизно|повний [за замовчуванням: повний]
--історія-рівень=повна (за замовчуванням) призводить до того, що Helgrind збирає достатньо інформації про
"старий" доступ до того, що він може створити дві траси стеку в звіті про перегони - обидві стека
трасування для поточного доступу та трасування для старішого, конфліктуючого доступу. До
обмежити використання пам'яті, "старі" траси стека доступу обмежені максимум 8 записами,
навіть якщо --число абонентів значення більше.

Збір такої інформації є дорогим як у швидкості, так і в пам’яті, особливо для
програми, які виконують багато подій міжпотокової синхронізації (блокування, розблокування тощо).
Без такої інформації важче відстежити першопричини рас.
Тим не менш, вам може не знадобитися в ситуаціях, коли ви просто хочете перевірити наявність
наявність або відсутність рас, наприклад, при виконанні регресійного тестування a
раніше програма без гонок.

--історія-рівень=немає є протилежною крайністю. Це змушує Хельгрінда не збирати жодного
інформація про попередні звернення. Це може бути значно швидше, ніж
--історія-рівень=повна.

--історія-рівень=прибл забезпечує компроміс між цими двома крайнощами. Це викликає
Helgrind, щоб показати повну трасу для подальшого доступу та приблизну інформацію
щодо попереднього доступу. Ця приблизна інформація складається з двох стеків і
попередній доступ гарантовано відбувся десь між програмними пунктами
позначається двома стеками. Це не так корисно, як показ точного стека для
попередній доступ (як --історія-рівень=повна робить), але це краще, ніж нічого, і це
майже так само швидко, як --історія-рівень=немає.

--conflict-cache-size=N [за замовчуванням: 1000000]
Цей прапор впливає лише на --історія-рівень=повна.

Інформація про "старі" конфліктні доступи зберігається в кеші обмеженого розміру,
з управлінням у стилі LRU. Це необхідно, оскільки зберігати a непрактично
трасування стека для кожного окремого доступу до пам'яті, здійсненого програмою. Історичні відомості
на місцях, до яких ви не нещодавно зверталися, періодично відкидається, щоб звільнити місце в
кеш-пам'ять

Ця опція керує розміром кешу з точки зору кількості різної пам’яті
адреси, для яких зберігається конфліктна інформація про доступ. Якщо ви знайдете це
Helgrind показує помилки гонки лише з одним стеком замість очікуваних двох
стеків, спробуйте збільшити це значення.

Мінімальне значення — 10,000 30,000,000, а максимальне — XNUMX XNUMX XNUMX (в тридцять разів більше за замовчуванням
значення). Збільшення значення на 1 збільшує потребу Хельгрінда до пам’яті дуже
приблизно 100 байт, тому максимальне значення легко з’їсть три зайвих гігабайти або близько того
пам'яті.

--check-stack-refs=ні|так [за замовчуванням: так]
За замовчуванням Helgrind перевіряє всі звернення до пам’яті даних, здійснені вашою програмою. Цей прапор
дозволяє пропустити перевірку доступу до стеків потоків (локальних змінних). Це може
покращує продуктивність, але це відбувається за ціною пропущених гонок на даних, виділених стеком.

--ignore-thread-creation= [за замовчуванням: немає]
Контролює, чи слід ігнорувати всі дії під час створення потоку. За замовчуванням
увімкнено лише на Solaris. Solaris забезпечує вищу пропускну здатність, паралельність і
масштабованість, ніж інші операційні системи, ціною більш дрібного блокування
діяльність. Це означає, наприклад, що коли потік створюється під glibc, лише один
великий замок використовується для налаштування всіх ниток. Solaris libc використовує кілька дрібнозернистих блокувань
і потік творця відновлює свою діяльність якнайшвидше, залишаючи, наприклад
стек і послідовність налаштування TLS для створеного потоку. Ця ситуація бентежить Хельгрінда
оскільки передбачається, що між творцем і створеним існує якийсь хибний порядок
нитка; і тому багатьох видів гонок умов у додатку не буде
повідомили. Щоб запобігти такому помилковому порядку, для цього параметра командного рядка встановлено значення yes by
за замовчуванням на Solaris. Тому всі дії (завантаження, зберігання, клієнтські запити) ігноруються
протягом:

· Виклик pthread_create() у потоці творця

· фаза створення потоку (налаштування стека та TLS) у створеному потоці

Також нова пам'ять, виділена під час створення потоку, не відстежується, тобто звіти про перегони
там придушено. DRD робить те ж саме неявно. Це необхідно тому, що
Solaris libc кешує багато об’єктів і повторно використовує їх для різних потоків тощо
збиває з пантелику Хельгрінда.

DRD ВАРІАНТИ

--check-stack-var= [за замовчуванням: немає]
Контролює, чи DRD виявляє перегони даних у змінних стека. Перевірка змінних стеку
за замовчуванням вимкнено, тому що більшість програм не мають спільного використання змінних стеку
нитки.

--exclusive-threshold= [за замовчуванням: вимкнено]
Надрукуйте повідомлення про помилку, якщо будь-який мьютекс або блокування запису було утримувано довше, ніж час
вказано в мілісекундах. Ця опція дозволяє виявити боротьбу за блокування.

--join-list-vol= [за замовчуванням: 10]
Гонки даних, які відбуваються між оператором в кінці одного потоку та іншого потоку
може бути пропущено, якщо інформація про доступ до пам’яті відкидається відразу після того, як потік має
був приєднаний. Цей параметр дозволяє вказати, скільки об’єднаних потоків пам’яті
інформація про доступ має бути збережена.

--first-race-only= [за замовчуванням: немає]
Чи повідомляти лише про першу гонку даних, яку було виявлено в пам’яті
або всі перегони даних, які були виявлені в пам'яті.

--free-is-write= [за замовчуванням: немає]
Чи повідомляти про перегони між доступом до пам’яті та звільненням пам’яті. Увімкнення цього
опція може призвести до дещо повільнішої роботи DRD. Примітки:

· Не вмикайте цю опцію під час використання користувацьких розподільників пам'яті, які використовують
VG_USERREQ__MALLOCLIKE_BLOCK і VG_USERREQ__FREELIKE_BLOCK, тому що це
призводять до помилкових спрацьовувань.

· Не вмикайте цю опцію під час використання об'єктів з підрахунком посилань, оскільки це буде
призведе до помилкових спрацьовувань, навіть якщо цей код був належним чином анотований
ANNOTATE_HAPPENS_BEFORE і ANNOTATE_HAPPENS_AFTER. Дивіться, наприклад, вихід
наступна команда для прикладу: valgrind --tool=drd --free-is-write=yes
drd/tests/annotate_smart_pointer.

--report-signal-unlocked= [за замовчуванням: так]
Чи повідомляти про дзвінки pthread_cond_signal та pthread_cond_broadcast де
мьютекс, пов'язаний із сигналом через pthread_cond_wait or
pthread_cond_timed_waitне заблоковано на момент надсилання сигналу. Відправка сигналу
без утримання блокування на пов'язаному мьютексі є поширеною помилкою програмування, яка може
спричиняють слабкі расові умови та непередбачувану поведінку. Є деякі незвичайні
шаблони синхронізації, однак, де безпечно надіслати сигнал, не утримуючи a
блокувати пов'язаний мьютекс.

--segment-merging= [за замовчуванням: так]
Керує об’єднанням сегментів. Об’єднання сегментів – це алгоритм обмеження використання пам’яті
Алгоритм виявлення гонки даних. Вимкнення об’єднання сегментів може підвищити точність
так звані «інші сегменти», які відображаються у звітах про перегони, але також можуть викликати аут
помилки пам'яті.

--segment-merging-interval= [за замовчуванням: 10]
Виконуйте об’єднання сегментів лише після того, як буде створено вказану кількість нових сегментів
створений. Це розширений параметр конфігурації, який дозволяє вибрати, чи потрібно
мінімізувати використання пам’яті DRD, вибравши низьке значення або дозволивши DRD працювати швидше
вибираючи трохи вище значення. Оптимальне значення цього параметра залежить від
програма, що аналізується. Значення за замовчуванням добре працює для більшості програм.

--shared-threshold= [за замовчуванням: вимкнено]
Надрукуйте повідомлення про помилку, якщо блокування зчитувача утримується довше зазначеного часу
(у мілісекундах). Ця опція дозволяє виявити боротьбу за блокування.

--show-confl-seg= [за замовчуванням: так]
Показувати конфліктні сегменти у звітах про перегони. Оскільки ця інформація може допомогти знайти
через перегони даних цей параметр увімкнено за замовчуванням. Вимкнення цієї опції робить
вихід ДРД більш компактний.

--show-stack-usage= [за замовчуванням: немає]
Використання стека друку під час завершення потоку. Коли програма створює велику кількість
потоків стає важливим обмежити обсяг виділеної віртуальної пам'яті
стеки ниток. Ця опція дає змогу спостерігати, скільки пам’яті стека було
використовується кожним потоком клієнтської програми. Примітка: інструмент DRD сам виділяє деякі
тимчасові дані в стеку потоків клієнта. Місце, необхідне для цих тимчасових даних
повинен бути виділений клієнтською програмою, коли вона виділяє пам'ять стека, але ні
включено у використання стека, про яке повідомляє DRD.

--ignore-thread-creation= [за замовчуванням: немає]
Контролює, чи слід ігнорувати всі дії під час створення потоку. За замовчуванням
увімкнено лише на Solaris. Solaris забезпечує вищу пропускну здатність, паралельність і
масштабованість, ніж інші операційні системи, ціною більш дрібного блокування
діяльність. Це означає, наприклад, що коли потік створюється під glibc, лише один
великий замок використовується для налаштування всіх ниток. Solaris libc використовує кілька дрібнозернистих блокувань
і потік творця відновлює свою діяльність якнайшвидше, залишаючи, наприклад
стек і послідовність налаштування TLS для створеного потоку. Ця ситуація бентежить DRD
передбачає, що між автором і створеним потоком існує хибний порядок; і
тому багато видів гонок у додатку не повідомлятимуться. До
щоб запобігти такому помилковому порядку, цей параметр командного рядка за замовчуванням увімкнено
Соляріс. Тому всі дії (завантаження, зберігання, запити клієнтів) ігноруються під час:

· Виклик pthread_create() у потоці творця

· фаза створення потоку (налаштування стека та TLS) у створеному потоці

--trace-addr= [за замовчуванням: жоден]
Відстежуйте всю активність завантаження та зберігання для вказаної адреси. Цей варіант може бути
вказано більше одного разу.

--ptrace-addr= [за замовчуванням: жоден]
Відстежуйте всю активність завантаження та зберігання для вказаної адреси і продовжуйте це робити
після того, як пам'ять за цією адресою була звільнена та перерозподілена.

--trace-alloc= [за замовчуванням: немає]
Відстежуйте всі виділення та звільнення пам’яті. Може виробляти величезну кількість продукції.

--trace-barrier= [за замовчуванням: немає]
Відстежте всю бар’єрну активність.

--trace-cond= [за замовчуванням: немає]
Простежте всю активність умовної змінної.

--trace-fork-join= [за замовчуванням: немає]
Відстежувати створення всіх потоків і всі події припинення потоку.

--trace-hb= [за замовчуванням: немає]
Відстеження виконання ANNOTATE_HAPPENS_BEFORE(), ANNOTATE_HAPPENS_AFTER() і
Запити клієнта ANNOTATE_HAPPENS_DONE().

--trace-mutex= [за замовчуванням: немає]
Відстежуйте всю активність мьютекса.

--trace-rwlock= [за замовчуванням: немає]
Відстежуйте всю активність блокування читання-запису.

--trace-semaphore= [за замовчуванням: немає]
Відстежте всю активність семафорів.

МАСИВ ВАРІАНТИ

--куча= [за замовчуванням: так]
Вказує, чи потрібно виконувати профільування купи.

--heap-admin= [за замовчуванням: 8]
Якщо профілювання купи ввімкнено, надає кількість адміністративних байтів на блок
використання. Це має бути оцінка середнього значення, оскільки воно може відрізнятися. Наприклад,
розподільник, який використовується glibc в Linux, вимагає десь від 4 до 15 байт на блок,
залежно від різних факторів. Цей розподільник також вимагає місця адміністратора для звільнення
блоків, але Massif не може пояснити це.

--stacks= [за замовчуванням: немає]
Вказує, чи слід виконувати профільування стека. Ця опція уповільнює Massif
значно, тому за замовчуванням вимкнено. Зверніть увагу, що Massif припускає, що основний стек має
нульовий розмір під час запуску. Це неправда, але зробити інакше точно важко.
Крім того, починаючи з нуля краще вказує на розмір частини основного стека
над якими насправді контролює програма користувача.

--pages-as-heap= [за замовчуванням: немає]
Вказує Massif профільувати пам'ять на рівні сторінки, а не на блоці malloc'd
рівень. Подробиці див. вище.

--глибина= [за замовчуванням: 30]
Максимальна глибина дерев розподілу, записана для детальних знімків. Збільшуючи його
змусить Massif працювати дещо повільніше, використовувати більше пам’яті та виробляти більший вихід
файли.

--alloc-fn=
Функції, зазначені за допомогою цієї опції, будуть розглядатися як купа
функція розподілу, наприклад Танос. Це корисно для функцій, які є обгортками
Танос or new, що може заповнити дерева розподілу нецікавою інформацією.
Цю опцію можна вказати кілька разів у командному рядку, щоб назвати декілька
функції.

Зауважте, що названа функція буде оброблятися таким чином, лише якщо вона є верхнім записом у a
трасування стека або трохи нижче іншої функції, обробленої таким чином. Наприклад, якщо у вас є
функція malloc1 що обгортає Танос та malloc2 що обгортає malloc1, просто вказавши
--alloc-fn=malloc2 не матиме ефекту. Треба уточнити --alloc-fn=malloc1 as
добре. Це трохи незручно, але причина в тому, що перевірка на виділення
функції повільні, і це економить багато часу, якщо Massif може припинити переглядати
стек записів трасування, як тільки він знаходить той, який не відповідає, а не потрібно
продовжити всі записи.

Зауважте, що імена C++ розібрані. Зауважте також, що перевантажені імена C++ повинні бути записані
повністю. Одинарні лапки можуть знадобитися, щоб оболонка не розбивала їх.
Наприклад:

--alloc-fn='оператор новий (непідписаний, std::nothrow_t const&)'

--ігнорувати-fn=
Будь-яке пряме виділення купи (тобто виклик до Танос, new, тощо, або виклик функції
названий ан --alloc-fn option), що зустрічається у функції, визначеній цією опцією will
бути проігнорованим. Це в основному корисно для цілей тестування. Цей параметр можна вказати
кілька разів у командному рядку, щоб назвати кілька функцій.

будь-який перерозподіл ігнорованого блоку також буде ігноруватися, навіть якщо перерозподіл дзвінок робить
не зустрічаються в ігнорованій функції. Це уникає можливості негативного розміру купи
якщо ігноровані блоки зменшуються за допомогою перерозподіл.

Правила написання імен функцій C++ такі ж, як і для --alloc-fn вище.

--поріг= [за замовчуванням: 1.0]
Поріг значущості для виділення купи у відсотках від загального розміру пам’яті.
Записи дерева розподілу, які становлять менше цього, будуть агреговані. Зауважте, що
це слід вказати разом з однойменною опцією ms_print.

--peak-inaccuracy= [за замовчуванням: 1.0]
Massif не обов'язково фіксує фактичний пік глобального розподілу пам'яті; за
за замовчуванням він фіксує пік лише тоді, коли розмір глобального виділення пам’яті перевищує
попередній пік щонайменше на 1.0%. Це тому, що локальних розподілів може бути багато
піки на цьому шляху, і зробити детальний знімок для кожного з них було б дорого
і марнотратно, оскільки всі, крім одного, пізніше будуть викинуті. Ця неточність може бути
змінено (навіть до 0.0%) за допомогою цієї опції, але Massif буде працювати значно повільніше
число наближається до нуля.

--одиниця часу= [за замовчуванням: i]
Одиниця часу, яка використовується для профілювання. Є три можливості: інструкція
executed (i), що добре для більшості випадків; реальний (настінний) час (мс, тобто
мілісекунди), що іноді корисно; і байти, виділені/звільнені в купі
та/або стек (B), що корисно для дуже короткочасних програм і для тестування
цілей, оскільки він найбільш відтворений на різних машинах.

--detailed-freq= [за замовчуванням: 10]
Частота детальних знімків. З --detailed-freq=1, кожен знімок є детальним.

--max-snapshots= [за замовчуванням: 100]
Максимальна кількість записаних знімків. Якщо встановлено значення N, для всіх програм, крім дуже
короткочасних, остаточна кількість знімків буде від N/2 до N.

--massif-out-file= [за замовчуванням: masif.out.%p]
Запишіть дані профілю у файл, а не у вихідний файл за замовчуванням,
масив.вих. . The %p та %q Специфікатори формату можна використовувати для вбудовування ідентифікатора процесу
та/або вміст змінної середовища в імені, як у випадку з
основний варіант --файл журналу.

SGCHECK ВАРІАНТИ

Наразі немає параметрів командного рядка, що стосуються SGCheck.

BBV ВАРІАНТИ

--bb-out-file= [за замовчуванням: bb.out.%p]
Цей параметр вибирає назву основного блочного векторного файлу. The %p та %q формат
специфікатори можна використовувати для вбудовування ідентифікатора процесу та/або вмісту середовища
змінної в назві, як у випадку з основним параметром --файл журналу.

--pc-out-file= [за замовчуванням: pc.out.%p]
Цей параметр вибирає ім’я файлу ПК. Цей файл містить адреси лічильників програм
та інформацію про назву функції для різних базових блоків. Це можна використовувати разом
за допомогою основного блочного векторного файлу для швидкого перемотування вперед через імена функцій замість просто
інструкція зараховується. The %p та %q Специфікатори формату можна використовувати для вбудовування процесу
Ідентифікатор та/або вміст змінної середовища в імені, як у випадку з
основний варіант --файл журналу.

--interval-size= [за замовчуванням: 100000000]
Цей параметр вибирає розмір інтервалу для використання. За замовчуванням 100 мільйонів
інструкції, що є загальновживаним значенням. Можна використовувати інші розміри; менший
інтервали можуть допомогти програмам з більш дрібними фазами. Проте менший розмір інтервалу
може призвести до проблем із точністю через ефект розігріву (при швидкому перемотуванні різних
архітектурні об’єкти будуть неініціалізовані, і це займе деяку кількість
інструкції до того, як вони «розігріються» до стану, без якого буде повна симуляція
швидке перемотування вперед. Великі розміри інтервалів, як правило, пом’якшують це.)

--instr-count-only [за замовчуванням: немає]
Ця опція вказує інструменту відображати лише загальну кількість інструкцій, а не відображати
генерувати фактичний основний блочний векторний файл. Це корисно як для налагодження, так і для
збір інформації про кількість інструкцій без створення великого базового вектора блоків
файли.

ЛАКЕЙ ВАРІАНТИ

--basic-counts= [за замовчуванням: так]
Якщо ввімкнено, Lackey друкує наступну статистику та інформацію про
виконання клієнтської програми:

1. Кількість викликів функції, зазначеної в --fnname параметр (за замовчуванням
є основним). Якщо в програмі були вилучені символи, рахунок завжди буде
нуль.

2. Кількість зустрічаються умовних гілок, кількість і частка
ті взяті.

3. Кількість суперблоків, введених і завершених програмою. Зауважимо, що через
оптимізації, виконані JIT, це зовсім не точне значення.

4. Кількість гостьових інструкцій (x86, amd64, ppc тощо) та інструкцій IR
виконано. IR – це RISC-подібне проміжне представлення Valgrind, через яке всі
приладобудування виконано.

5. Співвідношення між деякими з цих показників.

6. Код виходу клієнтської програми.

--detailed-counts= [за замовчуванням: немає]
Якщо ввімкнено, Lackey друкує таблицю, що містить кількість завантажень, сховищ і ALU
операції, диференційовані за типами ІР. Типи ІК визначаються за ІК
назва ("I1", "I8", ... "I128", "F32", "F64" і "V128").

--trace-mem= [за замовчуванням: немає]
Коли ввімкнено, Lackey друкує розмір та адресу майже кожного доступу до пам’яті, здійсненого ним
Програма. Подробиці дивіться у коментарях у верхній частині файлу lakey/lk_main.c
про вихідний формат, як він працює та неточності в трасуванні адреси. Примітка
що цей варіант дає величезну кількість продукції.

--trace-superblocks= [за замовчуванням: немає]
Коли ввімкнено, Lackey друкує адресу кожного суперблока (один запис,
множинний вихід, лінійний фрагмент коду), що виконується програмою. Це в першу чергу з
інтерес до розробників Valgrind. Перегляньте коментарі у верхній частині файлу
lakey/lk_main.c для детальної інформації про вихідний формат. Зауважте, що цей параметр створює
великі обсяги продукції.

--fnname= [за замовчуванням: головний]
Змінює функцію, коли підраховуються виклики --basic-counts=так вказано.

Використовуйте valgrind.bin онлайн за допомогою сервісів onworks.net