valgrind - Интернет в облаке

ПРОГРАММА:

ИМЯ

valgrind - набор инструментов для отладки и профилирования программ

СИНТАКСИС

Valgrind [valgrind-опции] [ваша программа] [параметры вашей программы]

ОПИСАНИЕ

Valgrind это гибкая программа для отладки и профилирования исполняемых файлов Linux. Он состоит
ядра, которое обеспечивает синтетический ЦП в программном обеспечении, а также серию отладочных и
инструменты профилирования. Архитектура является модульной, поэтому новые инструменты могут быть легко созданы и
без нарушения существующей конструкции.

Некоторые из описанных ниже параметров работают со всеми инструментами Valgrind, а некоторые работают только с
несколько или один. Раздел MEMCHECK OPTIONS и те, что под ним, описывают конкретные инструменты
настройки.

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

ИНСТРУМЕНТ ВЫБОР ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Самый важный вариант.

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

BASIC ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Эти параметры работают со всеми инструментами.

-h --Помогите
Показать справку по всем параметрам, как для ядра, так и для выбранного инструмента. Если вариант
повторяется это эквивалентно даванию --help-отладка.

--help-отладка
Такой же как --Помогите, но также перечислены параметры отладки, которые обычно используются только для
Разработчики Valgrind.

--версия
Показать номер версии ядра Valgrind. У инструментов может быть своя версия
числа. Существует схема, гарантирующая, что инструменты будут работать только тогда, когда ядро
Известно, что они работают с версией. Это было сделано, чтобы свести к минимуму вероятность
странные проблемы, возникающие из-за несовместимости версий инструмента с ядром.

-q, --тихий
Работать в автоматическом режиме и печатать только сообщения об ошибках. Полезно, если у вас регресс
тесты или другое автоматизированное оборудование для тестирования.

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

--trace-children = [дефолт: нет]
Если этот параметр включен, Valgrind будет отслеживать подпроцессы, инициированные через Exec система
вызов. Это необходимо для многопроцессорных программ.

Обратите внимание, что Valgrind отслеживает дочерний элемент вилка (было бы трудно не
с вилка делает идентичную копию процесса), поэтому этот вариант, вероятно, плохой
названный. Однако большинство детей вилка звонки немедленно звоните Exec так или иначе.

--trace-children-skip = patt1, patt2, ...
Эта опция действует только тогда, когда --trace-children = да указан. Это позволяет
некоторые дети должны быть пропущены. Параметр принимает список шаблонов, разделенных запятыми, для
имена дочерних исполняемых файлов, которые Valgrind не должен отслеживать. Шаблоны могут
включать метасимволы? и *, которые имеют обычное значение.

Это может быть полезно для обрезки неинтересных ветвей из дерева процессов.
беги по Валгринду. Но будьте осторожны при его использовании. Когда Valgrind пропускает трассировку
в исполняемый файл, он не просто пропускает трассировку этого исполняемого файла, он также пропускает
отслеживание любого из дочерних процессов этого исполняемого файла. Другими словами, флаг не
просто заставляет трассировку останавливаться на указанных исполняемых файлах - она ​​пропускает трассировку
все поддеревья процессов, основанные на любом из указанных исполняемых файлов.

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

--child-silent-after-fork = [дефолт: нет]
Если этот параметр включен, Valgrind не будет отображать какие-либо данные отладки или ведения журнала для дочернего элемента.
процесс, возникший в результате вилка вызов. Это может сделать вывод менее запутанным (хотя
вводит в заблуждение) при работе с процессами, которые создают потомков. Это особенно
полезно в сочетании с --trace-children =. Использование этой опции также настоятельно
рекомендуется, если вы запрашиваете вывод XML (--xml = да), поскольку в противном случае XML из
ребенок и родитель могут смешаться, что обычно делает его бесполезным.

--vgdb = [дефолт: да]
Valgrind предоставит функцию "gdbserver", когда --vgdb = да or --vgdb = полный is
указано. Это позволяет внешнему отладчику GNU GDB контролировать и отлаживать вашу программу.
когда он работает на Valgrind. --vgdb = полный влечет за собой значительные накладные расходы на производительность, но
предоставляет более точные точки останова и наблюдения. См. Раздел Отладка вашей программы с помощью
Подробное описание можно найти в gdbserver и GDB от Valgrind.

Если встроенный gdbserver включен, но в настоящее время gdb не используется, vgdb
Утилита командной строки может отправлять "команды мониторинга" в Valgrind из оболочки. В
Ядро Valgrind предоставляет набор команд монитора Valgrind. Инструмент может опционально
предоставлять специфические для инструмента команды монитора, которые задокументированы в специфичном для инструмента
главы.

--vgdb-error = [дефолт: 999999999]
Используйте эту опцию, когда gdbserver Valgrind включен с --vgdb = да or --vgdb = полный.
Инструменты, которые сообщают об ошибках, будут ждать сообщения об "числовых" ошибках перед зависанием.
программа и ждет, пока вы подключитесь к GDB. Отсюда следует, что значение нуля
вызовет запуск gdbserver до выполнения вашей программы. Это
обычно используется для вставки точек останова GDB перед выполнением, а также работает с инструментами
которые не сообщают об ошибках, например Massif.

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

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

Ценности ввод в эксплуатацию выход валгриндабексит соответственно указывают на вызов gdbserver
перед выполнением вашей программы, после последней инструкции вашей программы, на
Аномальный выход Valgrind (например, внутренняя ошибка, нехватка памяти, ...).

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

· ВСЕ указать комплектацию. Это эквивалентно
--vgdb-stop-at = запуск, выход, valgrindabexit.

· нет для пустого набора.

--track-fds = [дефолт: нет]
Если этот параметр включен, Valgrind будет распечатывать список дескрипторов открытых файлов при выходе или при
запрос через команду монитора gdbserver v.info open_fds. Вместе с каждым файлом
дескриптор печатается обратная трассировка стека того, где файл был открыт, и любые детали
относящиеся к дескриптору файла, например к имени файла или деталям сокета.

- отметка времени = [дефолт: нет]
Если этот параметр включен, каждому сообщению предшествует указание истекших настенных часов.
время с момента запуска, выраженное в днях, часах, минутах, секундах и миллисекундах.

--log-fd = [дефолт: 2, stderr]
Указывает, что Valgrind должен отправлять все свои сообщения в указанный файл
дескриптор. По умолчанию 2 - это стандартный канал ошибок (stderr). Обратите внимание, что это может
вмешиваться в собственное использование клиентом stderr, так как вывод Valgrind будет
чередуется с любым выводом, который клиент отправляет на stderr.

--log-файл =
Указывает, что Valgrind должен отправлять все свои сообщения в указанный файл. Если
имя файла пустое, это вызывает прерывание. Есть три специальных спецификатора формата, которые
можно использовать в имени файла.

%p заменяется идентификатором текущего процесса. Это очень полезно для программ,
вызывать несколько процессов. ВНИМАНИЕ: если вы используете --trace-children = да и твоя программа
вызывает несколько процессов ИЛИ ваша программа разветвляется без последующего вызова exec, и
вы не используете этот спецификатор (или %q спецификатор ниже), вывод Valgrind из всех
эти процессы будут помещены в один файл, возможно, беспорядочно или неполно.

% q {FOO} заменяется содержимым переменной окружения FOO, Если {ФОО}
часть деформирована, это вызывает прерывание. Этот спецификатор требуется редко, но очень
полезно в определенных обстоятельствах (например, при запуске программ MPI). Идея в том, что вы
укажите переменную, которая будет устанавливаться по-разному для каждого процесса в задании, для
пример BPROC_RANK или что-то еще, что применимо в вашей настройке MPI. Если названный
переменная окружения не установлена, это вызывает прерывание. Обратите внимание, что в некоторых оболочках {
и } символы могут нуждаться в экранировании обратной косой чертой.

%% заменяется на %.

Если % за ним следует любой другой символ, это вызывает прерывание.

Если имя файла указывает относительное имя файла, оно помещается в начальное имя программы.
рабочий каталог: это текущий каталог, когда программа запустила свой
выполнение после вилки или после выполнения. Если он указывает абсолютное имя файла (т. Е.
начинается с '/'), затем помещается туда.

--log-socket =
Указывает, что Valgrind должен отправлять все свои сообщения на указанный порт в
указанный IP-адрес. Порт можно не указывать, и в этом случае используется порт 1500. Если
невозможно установить соединение с указанным сокетом, Valgrind возвращается к записи
вывод в стандартную ошибку (stderr). Эта опция предназначена для использования в
в сочетании с программой valgrind-listener. Для получения дополнительной информации см.
комментарий в руководстве.

СВЯЗАННАЯ С ОШИБКОЙ ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Эти параметры используются всеми инструментами, которые могут сообщать об ошибках, например, Memcheck, но не
Кэшгринд.

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

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

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

Рекомендуемые параметры, которые необходимо передать графическому интерфейсу при запросе вывода XML: --xml = да
чтобы включить вывод XML, --xml-файл для отправки вывода XML в (предположительно с выбранным графическим интерфейсом)
файл, --лог-файл для отправки вывода простого текста во второй файл, выбранный графическим интерфейсом,
--child-silent-after-fork = даи -q ограничить вывод простого текста до критических
сообщения об ошибках, созданные самим Valgrind. Например, невозможность прочитать указанный
Файл подавления считается критическим сообщением об ошибке. Таким образом, для успешного
запустить текстовый выходной файл будет пустым. Но если он не пустой, то он будет содержать
важная информация, о которой следует знать пользователю графического интерфейса.

--xml-fd = [дефолт: -1, отключен]
Указывает, что Valgrind должен отправлять выходные данные XML в указанный файловый дескриптор.
Его необходимо использовать вместе с --xml = да.

--xml-файл =
Указывает, что Valgrind должен отправлять выходные данные XML в указанный файл. Это должно быть
используется вместе с --xml = да, Любые %p or %q последовательности, появляющиеся в имени файла
раскрываются точно так же, как и для --лог-файл. Смотрите описание
of --лог-файл для получения информации.

--xml-socket =
Указывает, что Valgrind должен отправлять свой XML-вывод на указанный порт по указанному
Айпи адрес. Его необходимо использовать вместе с --xml = да. Форма аргументации такова:
то же самое, что используется --log-сокет. См. Описание --log-сокет для дальнейшего


--xml-user-comment =
Встраивает дополнительную строку комментария пользователя в начало вывода XML. Работает только когда
--xml = да указан; в противном случае игнорируется.

--demangle = [дефолт: да]
Включение / отключение автоматического распознавания (декодирования) имен C ++. Включено по умолчанию. Когда
включен, Valgrind попытается преобразовать закодированные имена C ++ обратно во что-то
приближается к оригиналу. Деманглер обрабатывает символы, искаженные g ++ версии 2.X,
3.X и 4.X.

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

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

Максимальное значение для этого - 500. Обратите внимание, что более высокие настройки заставят Valgrind запускать
немного медленнее и занимает немного больше памяти, но может быть полезно при работе с
программы с глубоко вложенными цепочками вызовов.

--unw-stack-scan-thresh = [дефолт: 0] , --unw-stack-scan-frames = [дефолт:
5]
Поддержка сканирования стека доступна только для целей ARM.

Эти флаги включают и управляют раскручиванием стека при сканировании стека. Когда нормальный
механизмы раскрутки стека - использование записей Dwarf CFI и следование указателям на фрейм
- сбой, сканирование стека может восстановить трассировку стека.

Обратите внимание, что сканирование стека - неточный эвристический механизм, который может дать очень
вводящие в заблуждение результаты или их отсутствие. Его следует использовать только в экстренных случаях, когда нормальный
разматывание не удается, и, тем не менее, важно иметь следы стека.

Сканирование стопки - это простой метод: разматыватель читает слова из стопки, и
пытается угадать, какие из них могут быть обратными адресами, проверяя, не
точка сразу после инструкций по вызову ARM или Thumb. Если да, то слово добавляется к
обратная трассировка.

Основная опасность возникает, когда вызов функции возвращается, оставляя свой адрес возврата.
отображается, и вызывается новая функция, но новая функция не перезаписывает старую
адрес. В результате трассировка может содержать записи для функций.
которые уже вернулись, и поэтому могут сильно сбивать с толку.

Второе ограничение этой реализации заключается в том, что она будет сканировать только страницу (4 КБ,
обычно), содержащий указатель начального стека. Если кадры стека большие, это
может привести к тому, что на трассе будут присутствовать только несколько (или даже не все). Кроме того, если вы
не повезло, и у них есть начальный указатель стека в конце страницы, на которой он находится,
сканирование может пропустить все интересные кадры.

По умолчанию сканирование стека отключено. Обычный вариант использования - запросить его, когда
В противном случае трассировка стека была бы очень короткой. Итак, чтобы включить его, используйте
--unw-stack-scan-thresh = число. Это требует от Valgrind попробовать использовать сканирование стека для
«расширить» трассировки стека, которые содержат меньше, чем количество кадров.

Если сканирование стека действительно происходит, оно генерирует только максимальное количество кадров.
указывается --unw-stack-scan-frames. Обычно сканирование стека генерирует так много
мусорные записи, что для этого значения по умолчанию установлено низкое значение (5). Ни в коем случае не будет
трассировка стека, превышающая значение, указанное параметром --num-callers, должна быть создана.

--error-limit = [дефолт: да]
Если этот параметр включен, Valgrind перестает сообщать об ошибках после 10,000,000 1,000 XNUMX в общей сложности, или XNUMX
разные, были замечены. Это сделано для того, чтобы механизм отслеживания ошибок
становятся огромными накладными расходами на производительность в программах с большим количеством ошибок.

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

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

Такие линии маркеров облегчают поиск ошибок и / или извлечение ошибок в
выходной файл, содержащий ошибки valgrind, смешанные с выводом программы.

Обратите внимание, что допустимы пустые маркеры. Таким образом, только использование маркера начала (или конца) является
возможное.

--sigill-Diagnostics = [дефолт: да]
Включение / отключение печати диагностики недопустимых инструкций. Включено по умолчанию, но
по умолчанию отключено, когда --тихий дано. По умолчанию всегда можно явно указать
переопределено предоставлением этой опции.

Если этот параметр включен, будет печататься предупреждающее сообщение вместе с некоторыми диагностическими данными всякий раз, когда
встречается инструкция, которую Valgrind не может декодировать или переводить, до того, как
программе выдается сигнал SIGILL. Часто неправильная инструкция указывает на ошибку в
программа или отсутствует поддержка конкретной инструкции в Valgrind. Но, некоторые
программы намеренно пытаются выполнить инструкцию, которая может отсутствовать, и перехватывают
сигнал SIGILL для обнаружения функций процессора. Использование этого флага позволяет
избегайте диагностического вывода, который вы иначе получили бы в таких случаях.

--show-below-main = [дефолт: нет]
По умолчанию трассировки стека для ошибок не показывают никаких функций, которые появляются под main
потому что в большинстве случаев это неинтересный материал библиотеки C и / или чепуха.
В качестве альтернативы, если main отсутствует в трассировке стека, трассировки стека не будут отображаться
любые функции ниже main-подобные функции, такие как glibc's __libc_start_main.
Кроме того, если main-подобные функции присутствуют в трассе, они нормированы как
(ниже главный), чтобы сделать вывод более детерминированным.

Если этот параметр включен, будут отображаться все записи трассировки стека и main-Как
функции не будут нормализованы.

--fullpath-after = [дефолт: не произошел источник пути]
По умолчанию Valgrind показывает только имена файлов в трассировке стека, но не полные пути к ним.
исходные файлы. При использовании Valgrind в крупных проектах, где исходники находятся в
несколько разных каталогов, это может быть неудобно. --fullpath-после обеспечивает
гибкое решение этой проблемы. Когда эта опция присутствует, путь к каждому
отображается исходный файл со следующим важным предупреждением: если string находится в
путь, затем путь до включительно string опускается, иначе путь будет показан
немодифицированный. Обратите внимание, что string не обязательно быть префиксом пути.

Например, рассмотрим файл с именем /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 /.

Если вы просто хотите увидеть полный путь, просто укажите пустую строку:
--fullpath-after =. Это не особый случай, а просто логическое следствие
выше правил.

Наконец, вы можете использовать --fullpath-после многократно. Любое его появление вызывает
Valgrind, чтобы переключиться на создание полных путей и применение вышеуказанного правила фильтрации. Каждый
произведенный путь сравнивается со всеми --fullpath-после-заданные строки, в
заказ указан. Первая совпадающая строка приводит к усечению пути как
описано выше. Если ничего не найдено, отображается полный путь. Это облегчает скалывание
префиксы, когда источники взяты из ряда несвязанных каталогов.

--extra-debuginfo-path = [дефолт: не определено и неиспользованный]
По умолчанию Valgrind ищет объекты отладки по нескольким хорошо известным путям, например
/ usr / lib / debug /.

Однако могут быть сценарии, в которых вы можете захотеть поместить объекты отладки в
произвольное расположение, например внешнее хранилище при запуске Valgrind на мобильном устройстве
с ограниченным локальным хранилищем. Другим примером может быть ситуация, когда у вас нет
разрешение на установку пакетов объектов отладки в системе, в которой вы работаете
Вальгринд.

В этих сценариях вы можете указать абсолютный путь в качестве дополнительного, последнего места для
Valgrind для поиска объектов отладки, указав
--extra-debuginfo-path = / путь / к / отладке / объектам. Данный путь будет добавлен к
абсолютный путь к искомому объекту. Например, если Valgrind ищет
debuginfo для /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.

В некоторых сценариях может быть удобно читать отладочную информацию из объектов, хранящихся в
разная машина. С этим флагом Valgrind будет запрашивать сервер debuginfo, работающий на
ipaddr и прослушивание порта порта, если он не может найти объект debuginfo в локальном
файловая система.

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

Если Valgrind ищет отладочную информацию для /w/x/y/zz.so, используя сервер debuginfo, он
удалит компоненты пути и просто запросит zz.so на сервере. Что в
Turn будет искать соответствующий объект debuginfo только в своем текущем рабочем каталоге.

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

Обратите внимание, что проверяет соответствие между первичными и отладочными объектами, используя GNU debuglink CRC
схемы, выполняются даже при использовании сервера debuginfo. Чтобы отключить такую ​​проверку,
вам также необходимо указать --allow-mismatched-debuginfo = yes.

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

--allow-mismatched-debuginfo = нет | да [нет]
При чтении debuginfo из отдельных объектов debuginfo Valgrind по умолчанию проверяет
совпадение объектов main и debuginfo с использованием механизма отладки GNU. Этот
гарантирует, что он не читает debuginfo из устаревших объектов debuginfo, и
также гарантирует, что Valgrind не может дать сбой в результате несоответствия.

Эта проверка может быть отменена с помощью --allow-mismatched-debuginfo = yes. Это может быть
полезно, когда объекты debuginfo и main не были разделены должным образом. Быть
осторожно при использовании: он отключает все проверки согласованности, а Valgrind
наблюдается сбой, когда объекты main и debuginfo не совпадают.

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

--gen-suppressions = [дефолт: нет]
При установке на Да, Valgrind будет останавливаться после каждой отображаемой ошибки и печатать строку:

---- Подавление печати? --- [Возврат / N / n / Y / Y / C / c] ----

Прессование Retэта информация поможет вам разобраться, почему Gamer’s Galaxy — ваш лучший выбор. N Ret or n Ret, заставляет Valgrind продолжать выполнение без печати
подавление этой ошибки.

Прессование Y Ret or y Ret заставляет Valgrind записывать подавление для этой ошибки. Вы можете
затем вырежьте и вставьте его в файл подавления, если вы не хотите слышать о
ошибка в будущем.

При установке на ВСЕ, Valgrind будет печатать подавление для каждой сообщенной ошибки, без
опрашивает пользователя.

Этот параметр особенно полезен с программами на C ++, поскольку он выводит на печать
подавление с искаженными именами по мере необходимости.

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

Иногда две разные ошибки подавляются одним и тем же подавлением, и в этом случае
Valgrind будет выводить подавление более одного раза, но вам нужно только одно
скопируйте в свой файл подавления (но наличие более одного не вызовет проблем). Также,
имя подавления дается как ; имя не
действительно важно, он используется только с -v опция, которая распечатывает все использованные подавления
Records.

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

--dsymutil = нет | да [да]
Эта опция актуальна только при запуске Valgrind в Mac OS X.

Mac OS X использует схему связывания отложенной отладочной информации (debuginfo). Когда объект
файлы, содержащие debuginfo, связаны с .dylib или исполняемым файлом, debuginfo
не копируется в окончательный файл. Вместо этого debuginfo необходимо связать вручную с помощью
запуск системной утилиты dsymutil для исполняемого файла или .dylib. В
результирующая объединенная информация об отладке помещается в каталог вместе с исполняемым файлом или
.dylib, но с расширением .dSYM.

В --dsymutil = нет, Valgrind обнаружит случаи, когда каталог .dSYM либо
отсутствует или присутствует, но не соответствует связанному исполняемому файлу или
.dylib, скорее всего потому, что он устарел. В этих случаях Valgrind напечатает
предупреждающее сообщение, но не предпринимайте дальнейших действий.

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

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

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

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

Вам может потребоваться использовать эту опцию, если ваша программа имеет большие массивы, размещенные в стеке.
Valgrind отслеживает указатель стека вашей программы. Если он изменится более чем на
пороговое значение, Valgrind предполагает, что ваша программа переключается на другой стек, и
Memcheck ведет себя иначе, чем при изменении указателя стека меньше, чем
порог. Обычно эта эвристика работает хорошо. Однако, если ваша программа выделяет большие
структур в стеке, эта эвристика будет обманута, и Memcheck впоследствии
сообщать о большом количестве недействительных обращений к стеку. Эта опция позволяет вам изменить
порог на другое значение.

Вам следует рассматривать использование этой опции только в том случае, если отладочные данные Valgrind направляют вас на
Сделай так. В этом случае он сообщит вам новый порог, который вы должны указать.

В общем, размещение больших структур в стеке - плохая идея, потому что вы можете
легко исчерпать пространство стека, особенно в системах с ограниченной памятью или которые
рассчитывать на поддержку большого количества потоков, каждый с небольшим стеком, а также потому, что
проверка ошибок, выполняемая Memcheck, более эффективна для данных, размещенных в куче
чем для данных, размещенных в стеке. Если вам нужно использовать эту опцию, вы можете захотеть
подумайте о том, чтобы переписать свой код, чтобы он размещался в куче, а не в стеке.

--main-stacksize = [дефолт: использование текущий 'ulimit' ценить]
Задает размер стека основного потока.

Чтобы упростить управление памятью, Valgrind резервирует все необходимое пространство для основного
стек потока при запуске. Это означает, что ему необходимо знать требуемый размер стека в
запускать.

По умолчанию Valgrind использует текущее значение ulimit для размера стека, или 16 МБ,
в зависимости от того, что ниже. Во многих случаях это дает размер стека в диапазоне от 8 до 16 МБ,
который почти никогда не переполняется для большинства приложений.

Если вам нужен больший общий размер стека, используйте --main-размер стека чтобы указать это. Только установите это
так высоко, как вам нужно, так как зарезервировано гораздо больше места, чем вам нужно (т. е. сотни
мегабайт больше, чем вам нужно) ограничивает распределители памяти Valgrind и может
уменьшить общий объем памяти, который может использовать Valgrind. Это только действительно
значение на 32-битных машинах.

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

--main-размер стека влияет только на размер стека для начального потока программы. Она имеет
не влияет на размер стеков потоков, поскольку Valgrind их не выделяет.

Возможно, вам понадобится использовать оба --main-размер стека и --max-стекфрейм вместе. это
важно понимать, что --main-размер стека устанавливает максимальный общий размер стека,
в то время как --max-стекфрейм определяет наибольший размер любого кадра стека. Вы будете
нужно проработать --main-размер стека ценность для себя (обычно, если ваш
Сбой приложений). Но Valgrind скажет вам необходимое --max-стекфрейм размер,
если необходимо.

Как обсуждается далее в описании --max-стекфрейм, требование большого
стек является признаком потенциальных проблем с переносимостью. Лучше всего разместить все
большие данные в памяти, выделенной кучей.

--max-thread = [дефолт: 500]
По умолчанию Valgrind может обрабатывать до 500 потоков. Иногда это число слишком
небольшой. Используйте этот параметр, чтобы указать другой предел. Например, --max-thread = 3000.

MALLOC () - СВЯЗАННЫЙ ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

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

--alignment = [дефолт: 8 or 16 году в зависимости on Платформа]
По умолчанию Valgrind's таНос, перераспределитьи т. д., вернуть блок, начальный адрес которого
Выровненный по 8 или 16 байт (значение зависит от платформы и соответствует
платформа по умолчанию). Этот параметр позволяет указать другое выравнивание. В
предоставленное значение должно быть больше или равно значению по умолчанию, меньше или равно
4096 и должно быть степенью двойки.

--redzone-size = [дефолт: зависит on орудие труда]
Валгринда маллок перераспределить и т.д., добавьте блоки заполнения до и после каждого блока кучи
выделены выполняемой программой. Такие блоки заполнения называются красными зонами. В
значение по умолчанию для размера красной зоны зависит от инструмента. Например, Memcheck добавляет и
защищает минимум 16 байтов до и после каждого блока, выделенного клиентом.
Это позволяет ему обнаруживать опустошение или переполнение блока размером до 16 байт.

Увеличение размера красной зоны позволяет обнаруживать выход за пределы больших расстояний,
но увеличивает объем памяти, используемый Valgrind. Уменьшение размера красной зоны приведет к
уменьшает объем памяти, необходимый Valgrind, но также снижает вероятность обнаружения
over / underruns, поэтому не рекомендуется.

редкий ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

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

--smc-check = [дефолт: полностью нефайловый для x86 / amd64 / s390x,
стек для другими арки]
Эта опция контролирует обнаружение Valgrind самомодифицирующегося кода. Если нет проверки
готово, когда программа выполняет некоторый код, а затем перезаписывает его новым кодом, и
выполняет новый код, Valgrind продолжит выполнять переводы, которые он сделал для
старый код. Это может привести к неправильному поведению и / или сбоям.

Для "современных" архитектур - все, кроме x86, amd64 или s390x - по умолчанию
is стек. Это потому, что правильная программа должна предпринимать явные действия для восстановления
Согласованность кэша DI после модификации кода. Валгринд наблюдает и чтит таких
действия, в результате чего самомодифицирующийся код прозрачно обрабатывается с нулевым
Дополнительная стоимость.

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

Значения четырех доступных настроек следующие. Нет обнаружения (нет),
обнаруживать самомодифицирующийся код в стеке (который используется GCC для реализации вложенных
функции) (стек), везде обнаруживать самомодифицирующийся код (ВСЕ) и обнаружить
самомодифицирующийся код везде, кроме файловых сопоставлений (полностью нефайловый).

Бег с ВСЕ заметно замедлит работу Валгринда. Бег с нет будет редко
ускорить процесс, поскольку в большинстве программ динамически генерируется очень мало кода.
Команда 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: main (inlinfo.c: 6)
== 15380 ==
== 15380 == Условный переход или перемещение зависит от неинициализированных значений
== 15380 == по адресу 0x8048550: fun_noninline (inlinfo.c: 6)
== 15380 == по 0x804850E: main (inlinfo.c: 34)
== 15380 ==
== 15380 == Условный переход или перемещение зависит от неинициализированных значений
== 15380 == по адресу 0x8048520: main (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: main (inlinfo.c: 33)
== 15377 ==
== 15377 == Условный переход или перемещение зависит от неинициализированных значений
== 15377 == по адресу 0x8048550: fun_d (inlinfo.c: 6)
== 15377 == по 0x8048550: fun_noninline (inlinfo.c: 41)
== 15377 == по 0x804850E: main (inlinfo.c: 34)
== 15377 ==
== 15377 == Условный переход или перемещение зависит от неинициализированных значений
== 15377 == по адресу 0x8048520: fun_d (inlinfo.c: 6)
== 15377 == по 0x8048520: main (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, Valgrind gdbserver создает 3 файла (2 с именами FIFO).
и файл разделяемой памяти mmap). Параметр префикса управляет каталогом и префиксом
для создания этих файлов.

--run-libc-freeres = [дефолт: да]
Эта опция актуальна только при запуске Valgrind в Linux.

Библиотека GNU C (libc.so), который используется всеми программами, может выделять память для
его собственное использование. Обычно, когда программа завершается, не беспокоит освобождение этой памяти -
в этом не было бы никакого смысла, поскольку ядро ​​Linux восстанавливает все ресурсы процесса, когда
процесс все равно завершится, так что это просто замедлит работу.

Авторы 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, которые немного изменят моделируемое поведение в
нестандартными или опасными способами, возможно, для помощи в моделировании странных объектов. К
по умолчанию подсказки не включены. Используйте с осторожностью! Известные на данный момент подсказки:

· слабые-ioctls: Будьте очень осторожны с обработкой ioctl; единственное предположение состоит в том, что размер
верно. Не требует инициализации полного буфера при записи.
Без этого при использовании некоторых драйверов устройств с большим количеством странных ioctl
команды становится очень утомительным.

· совместимость с предохранителями: Включите специальную обработку определенных системных вызовов, которые могут блокировать
в файловой системе FUSE. Это может быть необходимо при запуске Valgrind на
многопоточная программа, которая использует один поток для управления файловой системой FUSE и
другой поток для доступа к этой файловой системе.

· включить-внешний: Включите некоторую особую магию, необходимую, когда запущенная программа
сам Валгринд.

· без внутреннего префикса: Отключить печать префикса > перед каждым stdout или stderr
строка вывода во внутреннем Valgrind, запущенном внешним Valgrind. Это полезно
при запуске регрессионных тестов Valgrind во внешней / внутренней настройке. Обратите внимание, что
префикс > всегда будет печататься перед внутренними строками журнала отладки.

· нет-nptl-pthread-stackcache: Этот совет актуален только при запуске Valgrind на
Linux.

Библиотека GNU glibc pthread (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) Будьте очень осторожны с обработкой дверных системных вызовов
нераспознанные файловые дескрипторы дверей. Не требует наличия полного буфера.
инициализируется при записи. Без этого программы, использующие библиотека(3LIB) функциональность
с полностью проприетарной семантикой может сообщать о большом количестве ложных срабатываний.

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

· Значение --fair-sched = да активирует честный планировщик. Короче говоря, если несколько
потоки готовы к запуску, потоки будут планироваться циклически.
Этот механизм доступен не на всех платформах или версиях Linux. Если не
доступно, используя --fair-sched = да вызовет завершение работы Valgrind с ошибкой.

Вы можете обнаружить, что этот параметр улучшает общую скорость отклика, если вы используете
интерактивная многопоточная программа, например веб-браузер, на Valgrind.

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

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

--kernel-option = вариант1, вариант2, ...
Обработка системных вызовов и ioctl, возникающих из второстепенных вариантов ядра по умолчанию для
эта платформа. Это полезно для работы на взломанных ядрах или с модулями ядра.
которые поддерживают, например, нестандартные ioctl. Используйте с осторожностью. Если вы этого не сделаете
поймите, что делает эта опция, тогда она вам почти наверняка не понадобится. В настоящее время
известные варианты:

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

· Android-нет-HW-TLS: некоторые версии эмулятора Android для ARM не предоставляют
аппаратный регистр TLS (локальное состояние потока), и Valgrind аварийно завершает работу при запуске. Использовать
этот вариант выбрать программную поддержку TLS.

· Android-GPU-SGX5XX: используйте это для поддержки обработки проприетарных ioctl для
Графические процессоры серии PowerVR SGX 5XX на устройствах Android. Невозможность выбора этого не
вызвать проблемы со стабильностью, но может привести к тому, что Memcheck сообщит о ложных ошибках после
программа выполняет ioctls, специфичные для графического процессора.

· Android-GPU-adreno3xx: аналогично, используйте это для поддержки обработки проприетарных
ioctls для графических процессоров Qualcomm Adreno 3XX на устройствах Android.

--merge-recursive-frames = [дефолт: 0]
Некоторые рекурсивные алгоритмы, например реализации сбалансированного двоичного дерева, создают
множество различных трассировок стека, каждая из которых содержит циклы вызовов. Цикл определяется как
два идентичных значения программного счетчика, разделенные нулем или несколькими другими счетчиками программ
ценности. Valgrind может затем использовать много памяти для хранения всех этих трассировок стека. Это
плохое использование памяти, учитывая, что такие трассировки стека содержат повторяющиеся неинтересные
рекурсивные вызовы вместо более интересной информации, такой как функция, имеющая
инициировал рекурсивный вызов.

Опция --merge-recursive-frames = инструктирует Valgrind обнаруживать и объединять
рекурсивные циклы вызовов размером до кадры. Когда такой цикл
обнаруженный, Valgrind записывает цикл в трассировку стека как уникальный счетчик программы.

Значение 0 (по умолчанию) не вызывает слияния рекурсивных вызовов. Значение 1 вызовет
трассировки стека простых рекурсивных алгоритмов (например, факториальная реализация)
быть свернутым. Значение 2 обычно требуется для свертывания созданных трассировок стека.
рекурсивными алгоритмами, такими как двоичные деревья, быстрая сортировка и т. д. Более высокие значения могут быть
требуется для более сложных рекурсивных алгоритмов.

Примечание: рекурсивные вызовы обнаруживаются путем анализа значений счетчиков программ. Они не
обнаруживается по именам функций.

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

--avg-transtab-entry-size = [дефолт: 0, вещества использование инструментом при условии дефолт]
Средний размер переведенного базового блока. Этот средний размер используется для измерения
размер сектора. Каждый инструмент предоставляет значение по умолчанию, которое будет использоваться. Если это значение по умолчанию
слишком мал, секторы перевода заполнятся слишком быстро. Если это значение по умолчанию
значение слишком велико, значительная часть памяти сектора перевода будет неиспользована.
Обратите внимание, что средний размер перевода базового блока зависит от инструмента и может
зависят от параметров инструмента. Например, опция memcheck --track-origins = да увеличивается
размер основного блока переводов. Использовать --avg-transtab-размер записи настроить
размер секторов, чтобы получить память или избежать слишком большого количества повторных переводов.

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

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

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

Если ваше приложение использует много потоков и требует много памяти, вы можете получить
память за счет уменьшения размера этих стеков Valgrind с помощью параметра
--valgrind-размер стека.

--show-emwarns = [дефолт: нет]
Если этот параметр включен, Valgrind в некоторых случаях будет выдавать предупреждения об эмуляции процессора.
Обычно это неинтересно.

--require-text-symbol =: sonamepatt: fnnamepatt
Когда общий объект, имя которого совпадает Sonamepatt загружается в процесс,
изучите все текстовые символы, которые он экспортирует. Если ни один из них не подходит фннамепатт, распечатайте
сообщение об ошибке и прекратите запуск. Это позволяет гарантировать, что пробег
не продолжать, если данный общий объект не содержит конкретное имя функции.

Оба формата Sonamepatt и фннамепатт можно записать с помощью обычного ? и * подстановочные знаки. Для
пример: ": * libc.so *: foo? bar". Вы можете использовать символы, отличные от двоеточия, для разделения
два шаблона. Важно только, чтобы первый символ и разделитель
характер такие же. Например, приведенный выше пример можно также записать
"Q * libc.so * Qfoo? Bar", множественный
--require-текстовый символ разрешены флаги, и в этом случае загружаемые общие объекты
в процессе будет проверяться по всем из них.

Целью этого является поддержка надежного использования размеченных библиотек. Например,
предположим, у нас есть версия GCC libgomp.so который был помечен
аннотации в поддержку Helgrind. Слишком просто и запутанно загружать неправильную,
без аннотации libgomp.so в приложение. Идея такова: добавьте текстовый символ в
размеченная библиотека, например annotated_for_helgrind_3_6, а затем дать флаг
--require-text-symbol =: * libgomp * so *: annotated_for_helgrind_3_6 так что когда libgomp.so
загружается, Valgrind сканирует свою таблицу символов, и, если символ отсутствует, запускается
прервано, вместо того, чтобы молча продолжить работу с неразмеченной библиотекой. Обратите внимание, что вы
следует поместить весь флаг в кавычки, чтобы оболочки не расширяли * и ?
подстановочные знаки.

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

В настоящее время такая гибкость разрешена только для функций, связанных с malloc, используя
синоним сомаллок. Этот синоним можно использовать для всех инструментов, выполняющих стандартную замену.
функций, связанных с malloc (например, memcheck, massif, drd, helgrind, exp-dhat,
экс-sgcheck).

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

Примечание: soname разделяемой библиотеки elf можно получить с помощью readelf
утилита.

· Замены в статически связанной библиотеке выполняются с помощью NONE шаблону.
Например, если вы свяжетесь с libtcmalloc.a, memcheck будет работать правильно, если вы
дать возможность --soname-synonyms = somalloc = НЕТ. Обратите внимание, что шаблон NONE не будет
соответствовать основному исполняемому файлу и любой разделяемой библиотеке, не имеющей soname.

· Чтобы запустить сборку Firefox по умолчанию для Linux, в которой JEMalloc связан с
основной исполняемый файл, используйте --soname-synonyms = somalloc = НЕТ.

ОТЛАДКА ВАЛЬГРИНД ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

Также есть несколько вариантов отладки самого Valgrind. Вам не нужно их использовать
при нормальном течении вещей. Если вы хотите увидеть список, используйте --help-отладка опцию.

МЕМЧЕК ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--leak-check = [дефолт: резюме]
Если этот параметр включен, поиск утечек памяти после завершения клиентской программы. Если установлено на
резюме, в нем указано, сколько произошло утечек. Если установлено на полный or Да, каждая отдельная утечка
будет отображаться подробно и / или засчитываться как ошибка, как указано в параметрах
--показать-утечки-виды и - ошибки за виды утечек.

--leak-resolution = [дефолт: высокий]
При проверке утечек определяет, насколько Memcheck будет учитывать различные
обратные трассировки должны быть одинаковыми для целей объединения нескольких утечек в одну
отчет об утечке. При установке на низкокачественными, должны совпадать только первые две записи. Когда из, 4
записи должны совпадать. Когда высокая, все записи должны совпадать.

Для отладки хардкорных утечек вы, вероятно, захотите использовать --leak-resolution = высокое вместе
--num-callers = 40 или какое-то такое большое количество.

Обратите внимание, что - разрешение утечки настройка не влияет на способность Memcheck находить
утечки. Это только меняет способ представления результатов.

--show-Leak-types = [дефолт: определенный, возможный]
Задает виды утечек, отображаемые в полный поиск утечек одним из следующих способов:

· Список, разделенный запятыми, из одного или нескольких определенный косвенный возможное достижимый.

· ВСЕ указать комплектацию (все виды утечек). Это эквивалентно
--show-leak-types = определенный, косвенный, возможный, достижимый.

· нет для пустого набора.

--errors-for-Leak-types = [дефолт: определенный, возможный]
Задает типы утечек, которые будут считаться ошибками в полный поиск утечки. В is
указано аналогично --показать-утечки-виды

--leak-check-heuristics = [дефолт: все]
Задает набор эвристик проверки утечек, который будет использоваться во время поиска утечек. В
эвристика контролирует, какие внутренние указатели на блок заставляют его рассматривать как
достижимый. Эвристический набор задается одним из следующих способов:

· Список, разделенный запятыми, из одного или нескольких стандартная строка длина64 новый массив
множественное наследование.

· ВСЕ для активации полного набора эвристик. Это эквивалентно
--leak-check-heuristics = stdstring, length64, newarray, множественное наследование.

· нет для пустого набора.

Обратите внимание, что эта эвристика зависит от компоновки объектов, созданных
Компилятор C ++. Они были протестированы с некоторыми версиями gcc (например, 4.4 и 4.7). Они
может некорректно работать с другими компиляторами C ++.

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

· --show-reachable = нет --show-possible-lost = да эквивалентна
--show-leak-types = определенно, возможно.

· --show-reachable = нет --show-possible-lost = нет эквивалентна
--show-leak-types = определенно.

· --show-reachable = да эквивалентна --show-leak-types = все.

Обратите внимание, что --show-possible-lost = нет не действует, если --show-reachable = да указан.

--undef-значение-ошибки = [дефолт: да]
Управляет использованием отчетов Memcheck об ошибках неопределенных значений. Установите это на нет if
вы не хотите видеть ошибки неопределенных значений. Он также имеет побочный эффект превышения скорости.
немного вверх Memcheck.

--track-origins = [дефолт: нет]
Контролирует, отслеживает ли Memcheck происхождение неинициализированных значений. По умолчанию это
нет, что означает, что хотя он может сказать вам, что неинициализированное значение
используется опасным образом, он не может сказать вам, откуда взялось неинициализированное значение
из. Это часто затрудняет выявление основной проблемы.

При установке на ДаMemcheck отслеживает происхождение всех неинициализированных значений.
Затем, когда сообщается об ошибке неинициализированного значения, Memcheck попытается показать
происхождение стоимости. Источник может быть одним из следующих четырех мест: блок кучи,
выделение стека, запрос клиента или различные другие источники (например, вызов
битый).

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

Накладные расходы на производительность: отслеживание происхождения стоит дорого. Это вдвое снижает скорость Memcheck и
увеличивает использование памяти минимум на 100 МБ, а возможно и больше. Тем не менее это может
резко сократить усилия, необходимые для выявления основной причины неинициализированного
ценить ошибки, и поэтому часто это приводит к повышению производительности программиста, несмотря на то, что
медленно.

Точность: Memcheck довольно точно отслеживает происхождение. Избегать очень большого пространства и времени
накладные расходы сделаны некоторые приближения. Возможно, хотя и маловероятно, что
Memcheck сообщит о неверном происхождении или не сможет определить происхождение.

Обратите внимание, что комбинация --track-origins = да и --undef-value-errors = нет is
бессмысленно. Memcheck проверяет и отклоняет эту комбинацию при запуске.

--partial-load-ok = [дефолт: да]
Управляет тем, как Memcheck обрабатывает 32-, 64-, 128- и 256-битные естественно выровненные нагрузки из
адреса, для которых одни байты адресуются, а другие нет. Когда Да, такой
загрузка не вызывает ошибки адреса. Вместо этого загруженные байты из недопустимого
адреса помечаются как неинициализированные, а соответствующие юридическим адресам -
обрабатывается обычным способом.

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

Обратите внимание, что код, который ведет себя таким образом, нарушает стандарты ISO C / C ++,
и следует считать сломанным. По возможности такой код следует исправить.

--expendance-definedness-tests = [дефолт: нет]
Определяет, должен ли Memcheck использовать более точный, но и более дорогой (время
потребляющие) алгоритмы при проверке определенности значения. По умолчанию установлено
не делать этого, и этого обычно достаточно. Однако для высоко оптимизированного кода
valgrind может иногда неправильно жаловаться. Вызов valgrind с помощью
--exurance-definedness-tests = да помогает, но требует снижения производительности. Время выполнения
наблюдалась деградация на 25%, но дополнительные расходы во многом зависят от
приложение под рукой.

--keep-stacktraces = alloc | free | alloc-and-free | alloc-then-free | none [дефолт:
распределенный и свободный]
Управляет тем, какие трассировки стека следует сохранять для блоков malloc'd и / или free'd.

В Распределить потом освободить, трассировка стека записывается во время выделения и связана
с блоком. Когда блок освобождается, записывается вторая трассировка стека, и это
заменяет трассировку стека распределения. В результате любые ошибки "использования после бесплатного использования", связанные с
в этот блок может показывать только трассировку стека для того места, где блок был освобожден.

В бесплатно, и выделение, и стек освобождения отслеживают для блока
хранятся. Следовательно, ошибка "использовать после освобождения" покажет и то, и другое, что может привести к ошибке.
легче диагностировать. По сравнению с Распределить потом освободить, этот параметр немного увеличивает
Использование памяти Valgrind, поскольку блок содержит две ссылки вместо одной.

В Alloc, записывается (и сообщается) только трассировка стека распределения. С участием бесплатно,
записывается (и сообщается) только трассировка стека освобождения. Эти ценности несколько
уменьшить память Valgrind и использование процессора. Они могут быть полезны в зависимости от ошибки
типы, которые вы ищете, и уровень детализации, необходимый для их анализа. Для
Например, если вас интересуют только ошибки утечки памяти, достаточно записать
трассировка стека распределения.

В нет, для операций malloc и free трассировки стека не записываются. Если твой
программа выделяет много блоков и / или выделяет / освобождает из множества разных стеков
следы, это может значительно уменьшить требуемый процессор и / или память. Конечно, мало
будут сообщены подробности об ошибках, связанных с блоками кучи.

Обратите внимание, что после записи трассировки стека Valgrind сохраняет трассировку стека в памяти.
даже если на него не ссылается ни один блок. Некоторые программы (например, рекурсивные
алгоритмы) могут генерировать огромное количество трассировок стека. Если Valgrind использует слишком много
память в таких обстоятельствах, вы можете уменьшить требуемую память с помощью опций
--keep-stacktraces и / или используя меньшее значение для опции --количество звонящих.

--freelist-vol = [дефолт: 20000000]
Когда клиентская программа освобождает память, используя бесплатно (в C) или удалить (C ++), эта память
не сразу становится доступным для перераспределения. Вместо этого он отмечен
недоступен и помещен в очередь освобожденных блоков. Цель состоит в том, чтобы отложить до тех пор, пока
возможно момент, когда освободившаяся память возвращается в обращение. Этот
увеличивает шанс того, что Memcheck сможет обнаружить недействительный доступ к блокам
в течение некоторого значительного периода времени после их освобождения.

Эта опция определяет максимальный общий размер блоков в очереди в байтах.
Значение по умолчанию - двадцать миллионов байтов. Увеличение этого значения увеличивает общую сумму
памяти, используемой Memcheck, но может обнаруживать недопустимое использование освобожденных блоков, что может
в противном случае останетесь незамеченными.

--freelist-big-blocks = [дефолт: 1000000]
Делая блоки из очереди освобожденных блоков доступными для перераспределения,
Memcheck будет в приоритетном порядке повторно рассылать блоки размером больше или равным
--freelist-большие блоки. Это гарантирует, что освобождение больших блоков (в частности освобождение
блоки больше, чем --freelist-vol) не сразу приводит к повторному обращению
все (или многие) маленькие блоки в свободном списке. Другими словами, этот вариант
увеличивает вероятность обнаружения висящих указателей для «маленьких» блоков, даже
когда освобождаются большие блоки.

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

--workaround-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 проверяет освобождение блоков кучи с помощью функции, которая
совпадает с функцией распределения. То есть ожидает бесплатно использоваться для освобождения
блоки, выделенные таНос, удалять для блоков, выделенных новыйи Удалить[] для
блоки, выделенные новый[]. При обнаружении несоответствия выдается сообщение об ошибке. Это в
вообще важно, потому что в некоторых средах освобождение с несоответствующей функцией
может вызвать сбои.

Однако существует сценарий, при котором невозможно избежать таких несовпадений. Вот когда
пользователь предоставляет реализации новый/новый[] этот звонок таНос и удалять/Удалить[]
этот звонок бесплатно, и эти функции асимметрично встроены. Например, представьте
который Удалить[] встроен, но новый[] не является. В результате Memcheck "видит" все
Удалить[] звонки как прямые звонки на бесплатно, даже если исходный код программы не содержит
несоответствующие звонки.

Это вызывает множество сбивающих с толку и не относящихся к делу отчетов об ошибках.
--show-mismatched-frees = нет отключает эти проверки. Обычно не рекомендуется
отключите их, потому что в результате вы можете пропустить настоящие ошибки.

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

--malloc-fill =
Заполняет блоки, выделенные malloc, new и т. Д., Но не calloc, указанным
байт. Это может быть полезно при попытке избавиться от неясных проблем с повреждением памяти.
Выделенная область все еще рассматривается Memcheck как неопределенная - только эта опция
влияет на его содержимое. Обратите внимание, что --malloc-заполнить не влияет на блок памяти, когда
он используется в качестве аргумента для клиентских запросов VALGRIND_MEMPOOL_ALLOC или
ВАЛГРИНД_МАЛЛОКЛИКЕ_БЛОК.

--free-fill =
Заполняет блоки, освобожденные при освобождении, удалении и т. Д., Указанным байтовым значением. Это может быть
полезно при попытке вытряхнуть непонятные проблемы с повреждением памяти. Освободившаяся площадь составляет
все еще рассматривается Memcheck как недействительный для доступа - эта опция влияет только на его
содержание. Обратите внимание, что - бесплатное заполнение не влияет на блок памяти, когда он используется как
аргумент для клиентских запросов VALGRIND_MEMPOOL_FREE или VALGRIND_FREELIKE_BLOCK.

КАЧЕГРИНД ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

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

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

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

--cache-sim = нет | да [да]
Включает или отключает сбор данных о доступе к кешу и счетчиках промахов.

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

--cachegrind-out-file =
Записывать данные профиля в файл, а не в выходной файл по умолчанию,
cachegrind.out. . В %p и %q спецификаторы формата могут использоваться для встраивания процесса
ID и / или содержимое переменной среды в имени, как в случае с
основной вариант --лог-файл.

КАЛГРИНД ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--callgrind-out-file =
Записывать данные профиля в файл, а не в выходной файл по умолчанию,
callgrind.out. . В %p и %q спецификаторы формата могут использоваться для встраивания процесса
ID и / или содержимое переменной среды в имени, как в случае с
основной вариант --лог-файл. При создании нескольких дампов имя файла изменяется
дальше; см. ниже.

--dump-line = [дефолт: да]
Это указывает, что подсчет событий должен выполняться с детализацией исходной строки.
Это позволяет добавлять аннотации к источникам, которые скомпилированы с отладочной информацией.
(-g).

--dump-instr = [дефолт: нет]
Это указывает, что подсчет событий должен выполняться с детализацией для каждой инструкции.
Это позволяет аннотировать ассемблерный код. В настоящее время результаты могут быть только отображены
пользователя KCachegrind.

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

--compress-pos = [дефолт: да]
Эта опция влияет на формат вывода данных профиля. Он определяет, есть ли
числовые позиции всегда указываются как абсолютные значения или могут быть
относительно предыдущих чисел. Это уменьшает размер файла.

--combine-dumps = [дефолт: нет]
Когда этот параметр включен, когда должны быть сгенерированы несколько частей данных профиля, эти части
добавлен в тот же выходной файл. Не рекомендуется.

--dump-каждый-bb = [дефолт: 0, никогда]
Сбрасывать данные профиля каждые считать базовые блоки. Проверяется только, нужен ли дамп
при запуске внутреннего планировщика Valgrind. Следовательно, минимальная полезная настройка:
около 100000. Счетчик представляет собой 64-битное значение, чтобы сделать возможными длительные периоды дампа.

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

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

--dump-after =
Сбросить при выезде функция.

--instr-atstart = [дефолт: да]
Укажите, хотите ли вы, чтобы Callgrind запускал моделирование и профилирование с начала
программа. Если установлено значение no, Callgrind не сможет собирать информацию,
включая звонки, но у него будет самое большее замедление около 4, что является минимальным
Valgrind накладные расходы. Инструментарий можно активировать интерактивно через callgrind_control
-i на.

Обратите внимание, что результирующий граф вызовов, скорее всего, не будет содержать main, но будет
содержат все функции, выполняемые после включения инструментария. Приборы
также может программно включаться / отключаться. См. Включаемый файл Callgrind callgrind.h
для макроса, который вы должны использовать в исходном коде.

Для моделирования кеша результаты будут менее точными при включении инструментовки.
позже при запуске программы, так как в этот момент симулятор запускается с пустым кешем.
Включите сбор событий позже, чтобы справиться с этой ошибкой.

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

Чтобы посмотреть только на части вашей программы, у вас есть две возможности:

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

2. Включите / выключите состояние сбора по мере необходимости, чтобы видеть только счетчики событий.
находясь внутри той части программы, которую вы хотите профилировать.

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

Состояние коллекции можно переключать при входе и выходе из данной функции с помощью опции
--toggle-собрать. Если вы используете эту опцию, состояние коллекции должно быть отключено в
начало. Обратите внимание, что спецификация --toggle-собрать неявно устанавливает
--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 = [дефолт: нет]
Укажите, хотите ли вы выполнять моделирование прогнозирования ветвления. Другие счетчики событий
enabled: количество выполненных условных переходов и связанных пропусков предиктора
("Bc" / "Bcm"), выполненные косвенные переходы и связанные с ними промахи предсказателя адреса перехода
(«Би» / «Бим»).

ХЕЛГРИНД ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--free-is-write = нет | да [дефолт: нет]
Когда этот параметр включен (не по умолчанию), Helgrind обрабатывает освобождение памяти кучи, как если бы
память была написана сразу перед бесплатной. Это показывает расы, в которых память
на которую ссылается один поток и освобождает другой, но нет наблюдаемых
событие синхронизации, чтобы гарантировать, что ссылка произойдет до бесплатного.

Эта функция является новой в Valgrind 3.7.0 и считается экспериментальной. это
не включен по умолчанию, потому что его взаимодействие с пользовательскими распределителями памяти не
хорошо понят в настоящее время. Отзывы пользователей приветствуются.

--track-lockorders = нет | да [дефолт: да]
Когда этот параметр включен (по умолчанию), Helgrind выполняет проверку согласованности порядка блокировки. Для
некоторые программы с ошибками, большое количество сообщений об ошибках порядка блокировки может стать
раздражает, особенно если вас интересуют только ошибки гонки. Вы можете поэтому
Считаю полезным отключить проверку порядка блокировки.

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

Сбор такой информации требует больших затрат как с точки зрения скорости, так и с точки зрения памяти, особенно для
программы, которые выполняют множество событий синхронизации между потоками (блокировки, разблокировки и т. д.).
Без такой информации труднее отследить первопричины рас.
Тем не менее, он может вам не понадобиться в ситуациях, когда вы просто хотите проверить наличие
наличие или отсутствие гонок, например, при проведении регрессионного тестирования
ранее не использовалась гоночная программа.

--history-level = нет противоположная крайность. Это заставляет Хелгринд не собирать никаких
информация о предыдущих доступах. Это может быть значительно быстрее, чем
--history-level = полный.

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

--conflict-cache-size = N [дефолт: 1000000]
Этот флаг действует только на --history-level = полный.

Информация о «старых» конфликтующих доступах хранится в кэше ограниченного размера,
с управлением в стиле LRU. Это необходимо, потому что хранить
трассировка стека для каждого обращения к памяти, сделанного программой. Историческая справка
на не недавно посещенных местах периодически выбрасывается, чтобы освободить место в
кэш.

Эта опция контролирует размер кеша с точки зрения количества разной памяти.
адреса, для которых хранится противоречивая информация о доступе. Если вы обнаружите, что
Helgrind показывает ошибки гонки только с одним стеком вместо ожидаемых двух
стеки, попробуйте увеличить это значение.

Минимальное значение - 10,000 30,000,000, максимальное - XNUMX XNUMX XNUMX (в тридцать раз больше, чем по умолчанию).
ценить). Увеличение значения на 1 увеличивает потребность Helgrind в памяти на очень
примерно 100 байт, поэтому максимальное значение легко съест три дополнительных гигабайта или около того
памяти.

--check-stack-refs = нет | да [дефолт: да]
По умолчанию Helgrind проверяет все обращения к памяти данных, сделанные вашей программой. Этот флаг
позволяет пропустить проверку доступа к стекам потоков (локальным переменным). Это может
улучшают производительность, но это происходит за счет пропущенных гонок для данных, выделенных стеком.

--ignore-thread-creation = [дефолт: нет]
Определяет, следует ли игнорировать все действия во время создания потока. По умолчанию
включен только в Solaris. Solaris обеспечивает более высокую пропускную способность, параллелизм и
масштабируемость по сравнению с другими операционными системами за счет более тонкой блокировки
деятельность. Это означает, например, что когда поток создается в glibc, только один
большой замок используется для настройки всех потоков. Solaris libc использует несколько мелких блокировок.
и поток создателя возобновляет свою деятельность как можно скорее, оставляя, например,
стек и последовательность установки TLS в созданный поток. Эта ситуация смущает Хелгринд
поскольку предполагается, что между создателем и созданным
нить; и поэтому многие типы условий гонки в приложении не будут
сообщил. Чтобы предотвратить такой ложный заказ, для этого параметра командной строки установлено значение «Да».
по умолчанию в 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не заблокирован в момент отправки сигнала. Отправка сигнала
без удержания блокировки связанного мьютекса - распространенная ошибка программирования, которая может
вызывают неуловимые состояния гонки и непредсказуемое поведение. Есть какие-то необычные
шаблоны синхронизации, однако, где безопасно послать сигнал, не удерживая
заблокировать связанный мьютекс.

--segment-merging = [дефолт: да]
Управляет объединением сегментов. Слияние сегментов - это алгоритм ограничения использования памяти
алгоритм обнаружения гонки данных. Отключение объединения сегментов может повысить точность
так называемые «другие сегменты», отображаемые в отчетах о гонках, но также могут вызывать
ошибки памяти.

- сегмент-слияние-интервал = [дефолт: 10]
Выполняйте объединение сегментов только после того, как будет добавлено указанное количество новых сегментов.
созданный. Это расширенная опция конфигурации, которая позволяет выбрать, следует ли
минимизировать использование памяти DRD, выбрав низкое значение, или позволить DRD работать быстрее,
выбрав немного большее значение. Оптимальное значение этого параметра зависит от
анализируемая программа. Значение по умолчанию подходит для большинства программ.

--shared-threshold = [дефолт: выключенный]
Распечатать сообщение об ошибке, если блокировка считывателя удерживалась дольше указанного времени.
(в миллисекундах). Эта опция позволяет обнаруживать конфликт блокировок.

--show-confl-seg = [дефолт: да]
Показывать конфликтующие сегменты в отчетах о гонках. Поскольку эта информация может помочь найти
причина гонки данных, эта опция включена по умолчанию. Отключение этой опции делает
на выходе DRD более компактный.

--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-барьер = [дефолт: нет]
Отслеживайте всю барьерную активность.

--trace-cond = [дефолт: нет]
Отслеживайте все действия переменных условий.

--trace-fork-join = [дефолт: нет]
Отслеживайте создание всего потока и все события завершения потока.

--trace-hb = [дефолт: нет]
Отслеживание выполнения ANNOTATE_HAPPENS_BEFORE (), ANNOTATE_HAPPENS_AFTER () и
Клиентские запросы ANNOTATE_HAPPENS_DONE ().

--trace-mutex = [дефолт: нет]
Отслеживайте всю активность мьютексов.

--trace-rwlock = [дефолт: нет]
Отслеживайте все действия блокировки чтения и записи.

--trace-semaphore = [дефолт: нет]
Отслеживайте всю активность семафоров.

МАССИВ ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--heap = [дефолт: да]
Указывает, следует ли выполнять профилирование кучи.

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

--stacks = [дефолт: нет]
Указывает, следует ли выполнять профилирование стека. Эта опция замедляет Massif
сильно, и поэтому по умолчанию отключено. Обратите внимание, что Massif предполагает, что основной стек имеет
нулевой размер при запуске. Это неправда, но сделать иначе точно сложно.
Кроме того, начало с нуля лучше указывает размер части основного стека.
что пользовательская программа фактически контролирует.

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

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

--alloc-fn =
Функции, указанные в этом параметре, будут рассматриваться как куча.
функция распределения, такая как таНос. Это полезно для функций, которые являются оболочками для
таНос or новый, которые могут заполнить деревья размещения неинтересной информацией.
Эта опция может быть указана несколько раз в командной строке, чтобы назвать несколько
функции.

Обратите внимание, что указанная функция будет обрабатываться таким образом, только если это верхняя запись в
трассировка стека или чуть ниже другой функции, обработанной таким образом. Например, если у вас есть
функция маллок1 это обертывает таНоси маллок2 это обертывает маллок1, просто указав
--alloc-fn = malloc2 не будет иметь никакого эффекта. Вам необходимо указать --alloc-fn = malloc1 as
хорошо. Это немного неудобно, но причина в том, что проверка распределения
работает медленно, и это экономит много времени, если Massif может перестать просматривать
записи трассировки стека, как только он находит тот, который не соответствует, вместо того, чтобы
продолжить через все записи.

Обратите внимание, что имена C ++ размечены. Также обратите внимание, что перегруженные имена C ++ должны быть написаны
в полном объеме. Одиночные кавычки могут быть необходимы, чтобы оболочка не разбивала их.
Например:

--alloc-fn = 'оператор новый (без знака, std :: nothrow_t const &)'

--ignore-fn =
Любое прямое выделение кучи (т. Е. Вызов таНос, новыйи т. д. или вызов функции
названный --alloc-fn option), который встречается в функции, указанной этим параметром, будет
игнорировать. Это в основном полезно для целей тестирования. Этот вариант можно указать
несколько раз в командной строке, чтобы назвать несколько функций.

Любые перераспределить игнорируемого блока также будут проигнорированы, даже если перераспределить звонок делает
не встречается в игнорируемой функции. Это позволяет избежать отрицательного размера кучи.
если игнорируемые блоки сжаты с перераспределить.

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

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

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

--time-unit = [дефолт: i]
Единица времени, используемая для профилирования. Есть три возможности: инструкции
выполнено (i), что подходит для большинства случаев; реальное (настенные часы) время (мс, т. е.
миллисекунды), что иногда бывает полезно; и байты, выделенные / освобожденные в куче
и / или стек (B), что полезно для очень коротких программ и для тестирования
целей, потому что он наиболее воспроизводим на разных машинах.

--detailed-freq = [дефолт: 10]
Частота детальных снимков. С участием --detailed-freq = 1, каждый снимок детализирован.

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

--massif-out-file = [дефолт: массив выход.% p]
Записывать данные профиля в файл, а не в выходной файл по умолчанию,
массив. выход. . В %p и %q спецификаторы формата могут использоваться для встраивания идентификатора процесса
и / или содержимое переменной среды в имени, как в случае с
основной вариант --лог-файл.

СГЧЕК ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

В настоящее время нет никаких специфичных для SGCheck параметров командной строки.

ББВ ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--bb-out-file = [дефолт: bb.out.% p]
Эта опция выбирает имя базового векторного файла блока. В %p и %q формат
спецификаторы могут использоваться для встраивания идентификатора процесса и / или содержимого среды.
переменная в имени, как в случае с основным параметром --лог-файл.

--pc-out-file = [дефолт: pc.out.% p]
Эта опция выбирает имя файла ПК. В этом файле хранятся адреса счетчиков программ.
и информация об имени функции для различных базовых блоков. Это можно использовать вместе
с базовым векторным файлом блока для быстрой перемотки вперед по именам функций, а не просто
инструкция считается. В %p и %q спецификаторы формата могут использоваться для встраивания процесса
ID и / или содержимое переменной среды в имени, как в случае с
основной вариант --лог-файл.

--interval-size = [дефолт: 100000000]
Эта опция выбирает размер используемого интервала. По умолчанию 100 миллионов.
инструкции, что является часто используемым значением. Могут использоваться другие размеры; меньше
интервалы могут помочь программам с более мелкими фазами. Однако меньший размер интервала
может привести к проблемам с точностью из-за эффектов разогрева (при быстрой перемотке вперед различных
архитектурные особенности не будут инициализированы, и потребуется некоторое количество
инструкции, прежде чем они "разогреются" до состояния, при котором полная симуляция была бы без
перемотка вперед. Большие интервалы обычно смягчают это.)

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

ЛАКИ ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

--basic-counts = [дефолт: да]
При включении Lackey распечатывает следующую статистику и информацию о
выполнение клиентской программы:

1. Количество вызовов функции, заданной --fnname вариант (по умолчанию
главный). Если в программе были удалены символы, счет всегда будет
нулю.

2. Количество встреченных условных переходов, а также количество и доля
взятые.

3. Количество суперблоков, введенных и завершенных программой. Обратите внимание, что из-за
оптимизация, выполненная JIT, это вовсе не точное значение.

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

5. Соотношения между некоторыми из этих показателей.

6. Код выхода клиентской программы.

--detailed-counts = [дефолт: нет]
Когда включено, Lackey печатает таблицу, содержащую количество загрузок, хранилищ и ALU.
операции, дифференцированные по их типу IR. Типы IR идентифицируются по их IR
имя («I1», «I8», ... «I128», «F32», «F64» и «V128»).

--trace-mem = [дефолт: нет]
Когда он включен, Lackey печатает размер и адрес почти каждого доступа к памяти, сделанного
программа. См. Комментарии в верхней части файла blankey / lk_main.c для подробностей.
о формате вывода, о том, как он работает, и о неточностях в трассировке адреса. Примечание
что этот вариант дает огромное количество результатов.

--trace-superblocks = [дефолт: нет]
Когда включено, Lackey распечатывает адрес каждого суперблока (одна запись,
множественный выход, линейный фрагмент кода), выполняемый программой. Это прежде всего
интерес для разработчиков Valgrind. См. Комментарии вверху файла
лакей / lk_main.c для получения подробной информации о формате вывода. Обратите внимание, что этот параметр производит
большие объемы продукции.

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

Используйте valgrind онлайн с помощью сервисов onworks.net