valgrind.bin - Online na nuvem

PROGRAMA:

NOME

valgrind - um conjunto de ferramentas para depurar e criar perfis de programas

SINOPSE

Valgrind [opções de valgrind] [seu programa] [opções do seu programa]

DESCRIÇÃO

Valgrind é um programa flexível para depurar e criar perfis de executáveis ​​Linux. Consiste
de um núcleo, que fornece uma CPU sintética no software e uma série de depuração e
ferramentas de criação de perfis. A arquitetura é modular, para que novas ferramentas possam ser criadas facilmente e
sem perturbar a estrutura existente.

Algumas das opções descritas abaixo funcionam com todas as ferramentas Valgrind, e algumas só funcionam com
alguns ou um. A seção MEMCHECK OPTIONS e as abaixo descrevem ferramentas específicas
opções.

Esta página do manual cobre apenas o uso básico e opções. Para informações mais abrangentes,
consulte a documentação HTML em seu sistema:
$ INSTALL / share / doc / valgrind / html / index.html ou online:
http://www.valgrind.org/docs/manual/index.html.

TOOL SELEÇÃO OPÇÕES

A opção mais importante.

--tool = [predefinição: verificação de memória]
Execute a ferramenta Valgrind chamada nome da ferramenta, por exemplo, memcheck, cachegrind, callgrind, helgrind,
drd, maciço, lacaio, nenhum, exp-sgcheck, exp-bbv, exp-dhat, etc.

BASIC OPÇÕES

Essas opções funcionam com todas as ferramentas.

-h --Socorro
Mostra ajuda para todas as opções, tanto para o núcleo como para a ferramenta selecionada. Se a opção
é repetido é equivalente a dar --help-depurar.

--help-depurar
Igual a --Socorro, mas também lista as opções de depuração que geralmente são úteis apenas para
Desenvolvedores de Valgrind.

--versão
Mostra o número da versão do núcleo Valgrind. As ferramentas podem ter sua própria versão
números. Existe um esquema para garantir que as ferramentas executem apenas quando o núcleo
versão é aquela com a qual eles trabalham. Isso foi feito para minimizar as chances de
problemas estranhos decorrentes de incompatibilidades entre a versão da ferramenta e do núcleo.

-q, --quieto
Execute silenciosamente e imprima apenas mensagens de erro. Útil se você estiver executando uma regressão
testes ou ter algum outro equipamento de teste automatizado.

-v, --verbose
Seja mais prolixo. Fornece informações extras sobre vários aspectos do seu programa, como:
os objetos compartilhados carregados, as supressões usadas, o progresso da instrumentação
e mecanismos de execução e avisos sobre comportamento incomum. Repetindo a opção
aumenta o nível de verbosidade.

--trace-children = [predefinição: não]
Quando ativado, Valgrind rastreará em subprocessos iniciados por meio do exec .
ligar. Isso é necessário para programas multiprocessos.

Observe que Valgrind rastreia o filho de um garfo (seria difícil não,
desde garfo faz uma cópia idêntica de um processo), então esta opção é indiscutivelmente mal
nomeado. No entanto, a maioria dos filhos de garfo liga imediatamente liga exec de qualquer maneira.

--trace-children-skip = patt1, patt2, ...
Esta opção só tem efeito quando --trace-children = yes é especificado. Permite
algumas crianças devem ser ignoradas. A opção leva uma lista de padrões separados por vírgulas para
os nomes dos executáveis ​​filhos que o Valgrind não deve rastrear. Padrões podem
inclui os metacaracteres? e *, que têm o significado usual.

Isso pode ser útil para podar ramos desinteressantes de uma árvore de processos sendo
executado em Valgrind. Mas você deve ter cuidado ao usá-lo. Quando Valgrind ignora o rastreamento
em um executável, ele não apenas pula o rastreamento desse executável, mas também pula
rastrear qualquer um dos processos filho desse executável. Em outras palavras, a bandeira não
simplesmente faz com que o rastreamento pare nos executáveis ​​especificados - ele pula o rastreamento de
subárvores de todo o processo com raiz em qualquer um dos executáveis ​​especificados.

--trace-children-skip-by-arg = patt1, patt2, ...
Este é o mesmo que --trace-crianças-skip, com uma diferença: a decisão quanto a
se rastrear em um processo filho é feito examinando os argumentos para o filho
processo, em vez do nome de seu executável.

--child-silent-after-fork = [predefinição: não]
Quando ativado, o Valgrind não mostrará nenhuma saída de depuração ou registro para o filho
processo resultante de um garfo ligar. Isso pode tornar a saída menos confusa (embora
mais enganosa) ao lidar com processos que criam filhos. É particularmente
útil em conjunto com --trace-children =. O uso desta opção também é forte
recomendado se você estiver solicitando saída XML (--xml = sim), caso contrário, o XML de
filho e pai podem ficar confusos, o que geralmente torna isso inútil.

--vgdb = [predefinição: sim]
Valgrind fornecerá a funcionalidade "gdbserver" quando --vgdb = sim or --vgdb = full is
Especificadas. Isso permite que um depurador GNU GDB externo controle e depure seu programa
quando é executado em Valgrind. --vgdb = full incorre em sobrecargas de desempenho significativas, mas
fornece pontos de interrupção e pontos de controle mais precisos. Consulte Depurando seu programa usando
Valgrind's gdbserver e GDB para uma descrição detalhada.

Se o gdbserver incorporado estiver habilitado, mas nenhum gdb estiver sendo usado no momento, o vgdb
O utilitário de linha de comando pode enviar "comandos de monitoramento" para Valgrind a partir de um shell. o
Valgrind core fornece um conjunto de comandos de monitor Valgrind. Uma ferramenta pode opcionalmente
fornecem comandos de monitor específicos da ferramenta, que são documentados na ferramenta específica
capítulo.

--vgdb-error = [predefinição: 999999999]
Use esta opção quando o Valgrind gdbserver está habilitado com --vgdb = sim or --vgdb = full.
Ferramentas que relatam erros irão esperar que os erros "numéricos" sejam relatados antes de congelar
o programa e esperando por você para se conectar com GDB. Segue-se que um valor de zero
fará com que o gdbserver seja iniciado antes que seu programa seja executado. Isto é
normalmente usado para inserir pontos de interrupção GDB antes da execução e também funciona com ferramentas
que não relatam erros, como Massif.

--vgdb-stop-at = [predefinição: Nenhum]
Use esta opção quando o Valgrind gdbserver está habilitado com --vgdb = sim or --vgdb = full.
O Valgrind gdbserver será invocado para cada erro após --vgdb-erro têm sido
relatado. Além disso, você pode solicitar que o Valgrind gdbserver seja chamado para outro
eventos, especificados de uma das seguintes maneiras:

· Uma lista separada por vírgulas de um ou mais dos inicialização saída valgrindabesit.

Os valores inicialização saída valgrindabesit respectivamente indicam para invocar gdbserver
antes de seu programa ser executado, após a última instrução de seu programa, em
Saída anormal do Valgrind (por exemplo, erro interno, memória insuficiente, ...).

Nota: inicialização e --vgdb-error = 0 ambos farão com que o Valgrind gdbserver seja invocado
antes de seu programa ser executado. o --vgdb-error = 0 Além disso, fará com que o seu
programa para parar em todos os erros subsequentes.

· todos os para especificar o conjunto completo. É equivalente a
--vgdb-stop-at = inicialização, saída, valgrindabexit.

· Nenhum para o conjunto vazio.

--track-fds = [predefinição: não]
Quando ativado, o Valgrind imprimirá uma lista de descritores de arquivos abertos na saída ou no
solicitação, por meio do comando gdbserver monitor v.info open_fds. Junto com cada arquivo
o descritor é impresso um backtrace da pilha de onde o arquivo foi aberto e quaisquer detalhes
relacionados ao descritor de arquivo, como o nome do arquivo ou detalhes do soquete.

- carimbo de hora = [predefinição: não]
Quando ativado, cada mensagem é precedida de uma indicação do relógio de parede decorrido
tempo desde a inicialização, expresso em dias, horas, minutos, segundos e milissegundos.

--log-fd = [predefinição: 2, stderr]
Especifica que Valgrind deve enviar todas as suas mensagens para o arquivo especificado
descritor. O padrão, 2, é o canal de erro padrão (stderr). Observe que isso pode
interferir com o uso de stderr pelo próprio cliente, pois a saída de Valgrind será
intercalado com qualquer saída que o cliente envia para stderr.

--log-file =
Especifica que Valgrind deve enviar todas as suas mensagens para o arquivo especificado. Se o
o nome do arquivo está vazio, isso causa um aborto. Existem três especificadores de formato especial que
pode ser usado no nome do arquivo.

%p é substituído pelo ID do processo atual. Isso é muito útil para programas que
invocar vários processos. AVISO: Se você usar --trace-children = yes e seu programa
invoca vários processos OU seu programa bifurca sem chamar exec depois, e
você não usa este especificador (ou o %q especificador abaixo), a saída Valgrind de todos
esses processos irão para um arquivo, possivelmente misturados e possivelmente incompletos.

% q {FOO} é substituído pelo conteúdo da variável de ambiente FOO. Se o {FOO}
parte está malformada, isso causa um aborto. Este especificador raramente é necessário, mas muito
útil em certas circunstâncias (por exemplo, ao executar programas MPI). A ideia é que você
especificar uma variável que será definida de forma diferente para cada processo no trabalho, para
exemplo BPROC_RANK ou o que for aplicável em sua configuração MPI. Se o nomeado
a variável de ambiente não está definida, causa um aborto. Observe que em alguns shells, o {
e } os caracteres podem precisar de escape com uma barra invertida.

%% é substituído por %.

Se um % é seguido por qualquer outro caractere, causa um aborto.

Se o nome do arquivo especifica um nome de arquivo relativo, ele é colocado na inicial do programa
diretório de trabalho: este é o diretório atual quando o programa iniciou seu
execução após a bifurcação ou após o exec. Se especificar um nome de arquivo absoluto (ou seja,
começa com '/') e é colocado lá.

--log-socket =
Especifica que Valgrind deve enviar todas as suas mensagens para a porta especificada no
endereço IP especificado. A porta pode ser omitida; nesse caso, a porta 1500 é usada. Se um
a conexão não pode ser feita ao soquete especificado, Valgrind volta a escrever
saída para o erro padrão (stderr). Esta opção deve ser usada em
conjunção com o programa valgrind-listener. Para obter mais detalhes, consulte o
comentário no manual.

RELACIONADO AO ERRO OPÇÕES

Essas opções são usadas por todas as ferramentas que podem relatar erros, por exemplo, Memcheck, mas não
Cachegrind.

--xml = [predefinição: não]
Quando habilitado, as partes importantes da saída (por exemplo, mensagens de erro da ferramenta) estarão em
Formato XML em vez de texto simples. Além disso, a saída XML será enviada para um
canal de saída diferente da saída de texto simples. Portanto, você também deve usar um
of --xml-fd, --arquivo-xml or --xml-soquete para especificar para onde o XML deve ser enviado.

Mensagens menos importantes ainda serão impressas em texto simples, mas porque o XML
saída e saída de texto simples são enviadas para diferentes canais de saída (o destino de
a saída de texto simples ainda é controlada por --log-fd, --arquivo de log e --log-soquete)
isso não deve causar problemas.

Esta opção visa tornar a vida mais fácil para ferramentas que consomem a produção do Valgrind como
entrada, como interfaces gráficas. Atualmente, esta opção funciona com Memcheck, Helgrind,
DRD e SGcheck. O formato de saída é especificado no arquivo
docs / internals / xml-output-protocol4.txt na árvore de origem para Valgrind 3.5.0 ou
mais tarde.

As opções recomendadas para uma GUI passar, ao solicitar saída XML, são: --xml = sim
para habilitar a saída XML, --arquivo-xml para enviar a saída XML para um (presumivelmente selecionado pela GUI)
arquivo, --arquivo de log para enviar a saída de texto simples para um segundo arquivo selecionado pela GUI,
--child-silent-after-fork = yes e -q para restringir a saída de texto simples para crítica
mensagens de erro criadas pelo próprio Valgrind. Por exemplo, falha ao ler um determinado
arquivo de supressão conta como uma mensagem de erro crítica. Desta forma, para um sucesso
executar o arquivo de saída de texto ficará vazio. Mas se não estiver vazio, então conterá
informações importantes das quais o usuário da GUI deve estar ciente.

--xml-fd = [predefinição: -1, Desativado]
Especifica que Valgrind deve enviar sua saída XML para o descritor de arquivo especificado.
Deve ser usado em conjunto com --xml = sim.

--xml-file =
Especifica que Valgrind deve enviar sua saída XML para o arquivo especificado. Deve ser
usado em conjunto com --xml = sim. Qualquer %p or %q sequências que aparecem no nome do arquivo
são expandidos exatamente da mesma maneira que são para --arquivo de log. Veja a descrição
of --arquivo de log para obter detalhes.

--xml-socket =
Especifica que Valgrind deve enviar sua saída XML para a porta especificada no especificado
Endereço de IP. Deve ser usado em conjunto com --xml = sim. A forma do argumento é
o mesmo que aquele usado por --log-soquete. Veja a descrição de --log-soquete por mais
Detalhes.

--xml-user-comment =
Incorpora uma string de comentário do usuário extra no início da saída XML. Só funciona quando
--xml = sim é especificado; ignorado de outra forma.

--demangle = [predefinição: sim]
Ativar / desativar a eliminação automática (decodificação) de nomes C ++. Ativado por padrão. Quando
habilitado, Valgrind tentará traduzir nomes C ++ codificados de volta para algo
aproximando-se do original. O demangler lida com símbolos mutilados por g ++ versões 2.X,
3.X e 4.X.

Um fato importante sobre a demangling é que os nomes das funções mencionados nas supressões
os arquivos devem estar em sua forma mutilada. Valgrind não desmancha nomes de função quando
procurando supressões aplicáveis, porque fazer o contrário faria com que a supressão
o conteúdo do arquivo depende do estado da máquina de degola de Valgrind, e também lento
correspondência de supressão para baixo.

--num-callers = [predefinição: 12]
Especifica o número máximo de entradas mostradas nos rastreamentos de pilha que identificam o programa
Localizações. Observe que os erros são comuns usando apenas os quatro principais locais de função
(o local na função atual e de seus três chamadores imediatos). Então, é isso
não afeta o número total de erros relatados.

O valor máximo para isso é 500. Observe que configurações mais altas farão Valgrind executar um
um pouco mais devagar e ocupar um pouco mais de memória, mas pode ser útil ao trabalhar com
programas com cadeias de chamadas profundamente aninhadas.

--unw-stack-scan-thresh = [predefinição: 0] , --unw-stack-scan-frames = [predefinição:
5]
O suporte de escaneamento de pilha está disponível apenas em alvos ARM.

Esses sinalizadores permitem e controlam o desenrolamento da pilha por meio da varredura da pilha. Quando o normal
mecanismos de desenrolamento da pilha - uso de registros Dwarf CFI e seguimento de ponteiro de quadro
- falha, a varredura da pilha pode recuperar o rastreamento da pilha.

Observe que a varredura de pilha é um mecanismo heurístico impreciso que pode dar muito
resultados enganosos ou mesmo nenhum. Deve ser usado apenas em emergências, quando normal
o desenrolamento falha e, no entanto, é importante ter rastreamentos de pilha.

A verificação da pilha é uma técnica simples: o desenrolador lê as palavras da pilha e
tenta adivinhar quais deles podem ser endereços de retorno, verificando se eles
aponte logo após as instruções de chamada ARM ou Thumb. Nesse caso, a palavra é adicionada ao
retrocesso.

O principal perigo ocorre quando uma chamada de função retorna, deixando seu endereço de retorno
exposta, e uma nova função é chamada, mas a nova função não substitui a antiga
Morada. O resultado disso é que o backtrace pode conter entradas para funções
que já voltaram, e por isso é muito confuso.

Uma segunda limitação desta implementação é que ela fará a varredura apenas da página (4 KB,
normalmente) contendo o ponteiro da pilha inicial. Se os frames da pilha forem grandes, isso
pode resultar em apenas alguns (ou nenhum) presentes no rastreamento. Além disso, se você
não têm sorte e têm um ponteiro de pilha inicial próximo ao final da página que o contém, o
a varredura pode perder todos os quadros interessantes.

Por padrão, a digitalização de pilha está desativada. O caso de uso normal é solicitá-lo quando um
o rastreamento de pilha seria muito curto. Então, para habilitá-lo, use
--unw-stack-scan-thresh = número. Isso solicita que Valgrind tente usar o escaneamento de pilha para
"estender" os rastreamentos de pilha que contêm menos do que quadros numéricos.

Se a digitalização da pilha ocorrer, ela gerará apenas no máximo o número de quadros
especificado por --unw-stack-scan-frames. Normalmente, a digitalização de pilha gera muitos
entradas de lixo que este valor é definido como um valor baixo (5) por padrão. Em nenhum caso
um rastreamento de pilha maior que o valor especificado por --num-callers seja criado.

--error-limit = [predefinição: sim]
Quando ativado, Valgrind para de relatar erros após 10,000,000 no total, ou 1,000
diferentes, foram vistos. Isso é para parar o mecanismo de rastreamento de erros de
tornando-se uma grande sobrecarga de desempenho em programas com muitos erros.

--error-exitcode = [predefinição: 0]
Especifica um código de saída alternativo para retornar se Valgrind relatou quaisquer erros no
corre. Quando definido com o valor padrão (zero), o valor de retorno de Valgrind sempre será
ser o valor de retorno do processo que está sendo simulado. Quando definido com um valor diferente de zero, que
valor é retornado em vez disso, se Valgrind detectar algum erro. Isso é útil para usar
Valgrind como parte de um conjunto de teste automatizado, uma vez que torna mais fácil detectar o teste
casos para os quais Valgrind relatou erros, apenas inspecionando códigos de retorno.

--error-markers = , [predefinição: Nenhum]
Quando os erros são emitidos como texto simples (ou seja, XML não usado), - marcadores de erro instrui para
produza uma linha contendo o começar (final) string antes (depois) de cada erro.

Essas linhas marcadoras facilitam a busca de erros e / ou extração de erros em um
arquivo de saída que contém erros valgrind misturados com a saída do programa.

Observe que marcadores vazios são aceitos. Então, apenas usar um marcador de início (ou fim) é
possível.

--sigill-diagnostics = [predefinição: sim]
Habilita / desabilita a impressão de diagnósticos de instrução ilegal. Ativado por padrão, mas
o padrão é desabilitado quando --quieto é dada. O padrão sempre pode ser explicitamente
substituído ao fornecer esta opção.

Quando habilitado, uma mensagem de aviso será impressa, juntamente com alguns diagnósticos, sempre que
uma instrução é encontrada que Valgrind não pode decodificar ou traduzir, antes do
programa recebe um sinal SIGILL. Freqüentemente, uma instrução ilegal indica um bug no
programa ou falta de suporte para a instrução particular em Valgrind. Mas alguns
programas tentam deliberadamente executar uma instrução que pode estar faltando e interceptar
o sinal SIGILL para detectar recursos do processador. Usar este sinalizador torna possível
evite a saída de diagnóstico que você obteria em tais casos.

--show-below-main = [predefinição: não]
Por padrão, os rastreamentos de pilha para erros não mostram nenhuma função que apareça abaixo principal
porque na maioria das vezes é material desinteressante da biblioteca C e / ou gobbledygook.
Alternativamente, se principal não está presente no rastreamento de pilha, os rastreamentos de pilha não serão exibidos
quaisquer funções abaixo principal- funções como glibc's __libc_start_main.
Além disso, se principal- funções semelhantes estão presentes no rastreamento, elas são normalizadas como
(abaixo a Principal), para tornar a saída mais determinística.

Se esta opção for ativada, todas as entradas de rastreamento de pilha serão mostradas e principal-gostar
funções não serão normalizadas.

--fullpath-after = [predefinição: não mostrar fonte caminhos]
Por padrão, o Valgrind mostra apenas os nomes de arquivos em rastreamentos de pilha, mas não os caminhos completos para
Arquivos Fonte. Ao usar Valgrind em grandes projetos onde as fontes residem
vários diretórios diferentes, isso pode ser inconveniente. --fullpath-depois fornece uma
solução flexível para este problema. Quando esta opção está presente, o caminho para cada
arquivo de origem é mostrado, com a seguinte advertência muito importante: se corda é encontrado em
o caminho, então o caminho até e incluindo corda é omitido, caso contrário, o caminho é mostrado
não modificado. Observe que corda não precisa ser um prefixo do caminho.

Por exemplo, considere um arquivo denominado /home/janedoe/blah/src/foo/bar/xyzzy.c. Especificando
--fullpath-after = / home / janedoe / blah / src / fará com que Valgrind mostre o nome como
foo / bar / xyzzy.c.

Como a string não precisa ser um prefixo, --fullpath-after = src / vai produzir
a mesma saída. Isso é útil quando o caminho contém
personagens. Por exemplo, o caminho / my / build / dir / C32A1B47 / blah / src / foo / xyzzy pode ser
podado para foo / xyzzy usando --fullpath-after = / blah / src /.

Se você simplesmente deseja ver o caminho completo, basta especificar uma string vazia:
--fullpath-after =. Este não é um caso especial, apenas uma consequência lógica do
regras acima.

Finalmente, você pode usar --fullpath-depois várias vezes. Qualquer aparência disso causa
Valgrind para alternar para a produção de caminhos completos e a aplicação da regra de filtragem acima. Cada
caminho produzido é comparado com todos os --fullpath-depois-cadeias especificadas, no
pedido especificado. A primeira string correspondente faz com que o caminho seja truncado como
descrito acima. Se nenhum corresponder, o caminho completo é mostrado. Isso facilita o corte
prefixos quando as fontes são retiradas de vários diretórios não relacionados.

--extra-debuginfo-path = [predefinição: indefinido e não utilizado]
Por padrão, o Valgrind procura em vários caminhos conhecidos para objetos de depuração, como
/ usr / lib / debug /.

No entanto, pode haver cenários em que você pode querer colocar objetos de depuração em um
localização arbitrária, como armazenamento externo ao executar Valgrind em um dispositivo móvel
com armazenamento local limitado. Outro exemplo pode ser uma situação em que você não tem
permissão para instalar pacotes de objetos de depuração no sistema onde você está executando
Valgrind.

Nesses cenários, você pode fornecer um caminho absoluto como um lugar final e extra para
Valgrind para pesquisar objetos de depuração, especificando
--extra-debuginfo-path = / path / to / debug / objects. O caminho fornecido será anexado ao
nome do caminho absoluto do objeto procurado. Por exemplo, se Valgrind está procurando
o debuginfo para /w/x/y/zz.so e --extra-debuginfo-path = / a / b / c é especificado, vai
procure um objeto de depuração em /a/b/c/w/x/y/zz.so.

Este sinalizador deve ser especificado apenas uma vez. Se for especificado várias vezes, apenas o
última instância é honrada.

--debuginfo-server = ipaddr: port [predefinição: indefinido e não utilizado]
Este é um novo recurso experimental introduzido na versão 3.9.0.

Em alguns cenários, pode ser conveniente ler informações de depuração de objetos armazenados em um
máquina diferente. Com este sinalizador, Valgrind irá consultar um servidor debuginfo em execução
ipaddr e ouvindo na porta da porta, se não conseguir encontrar o objeto debuginfo no local
sistema de arquivo.

O servidor debuginfo deve aceitar conexões TCP na porta da porta. O servidor debuginfo é
contido no arquivo de origem auxprogs / valgrind-di-server.c. Só servirá de
o diretório em que é iniciado. O padrão da porta é 1500 no cliente e no servidor, se
não especificado.

Se Valgrind procurar debuginfo para /w/x/y/zz.so usando o servidor debuginfo, ele
irá retirar os componentes do nome do caminho e simplesmente solicitar zz.so no servidor. Isso em
turn irá procurar apenas em seu diretório de trabalho atual por um objeto debuginfo correspondente.

Os dados debuginfo são transmitidos em pequenos fragmentos (8 KB), conforme solicitado pelo Valgrind.
Cada bloco é compactado usando LZO para reduzir o tempo de transmissão. A implementação tem
foi ajustado para melhor desempenho em um link de rede 802.11g (WiFi) de estágio único.

Observe que verifica a correspondência entre objetos primários e objetos de depuração, usando GNU debuglink CRC
esquema, são executados mesmo ao usar o servidor debuginfo. Para desativar essa verificação,
você também precisa especificar --allow-mismatched-debuginfo = yes.

Por padrão, o sistema de construção Valgrind irá construir valgrind-di-server para o alvo
plataforma, o que quase certamente não é o que você deseja. Até agora não fomos capazes de
descubra como obter automake / autoconf para compilá-lo para a plataforma de compilação. Se você quiser
para usá-lo, você terá que recompilá-lo manualmente usando o comando mostrado no topo do
auxprogs / valgrind-di-server.c.

--allow-mismatched-debuginfo = no | yes [não]
Ao ler debuginfo de objetos debuginfo separados, Valgrind irá, por padrão, verificar
que os objetos main e debuginfo correspondam, usando o mecanismo GNU debuglink. Esse
garante que ele não leia debuginfo de objetos debuginfo desatualizados, e
também garante que o Valgrind não trave como resultado de incompatibilidades.

Esta verificação pode ser substituída usando --allow-mismatched-debuginfo = yes. Isso pode ser
útil quando o debuginfo e os objetos principais não foram divididos da maneira adequada. Ser
cuidado ao usar isso, porém: desativa toda a verificação de consistência, e Valgrind
foi observado para travar quando os objetos principal e debuginfo não coincidem.

--suppressions = [predefinição: $ PREFIX / lib / valgrind / default.supp]
Especifica um arquivo extra do qual ler as descrições dos erros a serem suprimidos. Você pode
use até 100 arquivos de supressão extras.

--gen-suppressions = [predefinição: não]
Quando definido para sim, Valgrind fará uma pausa após cada erro mostrado e imprimirá a linha:

---- Supressão de impressão? --- [Return / N / n / Y / y / C / c] ----

Premente Retou N Ret or n Ret, faz com que Valgrind continue a execução sem imprimir um
supressão para este erro.

Premente Y Ret or y Ret faz com que Valgrind escreva uma supressão para este erro. Você pode
em seguida, corte e cole em um arquivo de supressão se você não quiser ouvir sobre o
erro no futuro.

Quando definido para todos os, Valgrind imprimirá uma supressão para cada erro relatado, sem
questionando o usuário.

Esta opção é particularmente útil com programas C ++, pois imprime o
supressões com nomes mutilados, conforme necessário.

Observe que as supressões impressas são as mais específicas possíveis. Você pode querer comum
até outros semelhantes, adicionando curingas aos nomes de funções e usando
curingas. Os recursos de curinga são poderosos, mas flexíveis, e com um pouco de
edição cuidadosa, você pode suprimir toda uma família de erros relacionados com
apenas algumas supressões.

Às vezes, dois erros diferentes são suprimidos pela mesma supressão, caso em que
Valgrind produzirá a supressão mais de uma vez, mas você só precisa ter uma
copie em seu arquivo de supressão (mas ter mais de um não causará problemas). Também,
o nome da supressão é dado como ; o nome não
realmente importa, ele só é usado com o -v opção que imprime todas as supressões usadas
Registros.

--input-fd = [predefinição: 0, padrão]
Ao usar --gen-suppressions = yes, Valgrind irá parar para ler a entrada do teclado
de você quando ocorrer cada erro. Por padrão, ele lê a entrada padrão (stdin),
o que é problemático para programas que fecham o stdin. Esta opção permite que você especifique
um descritor de arquivo alternativo para ler a entrada.

--dsymutil = não | sim [sim]
Esta opção só é relevante ao executar Valgrind no Mac OS X.

O Mac OS X usa um esquema de vinculação de informações de depuração adiadas (debuginfo). Quando objeto
arquivos contendo debuginfo são vinculados a um .dylib ou um executável, o debuginfo é
não copiado para o arquivo final. Em vez disso, o debuginfo deve ser vinculado manualmente por
executando dsymutil, um utilitário fornecido pelo sistema, no executável ou .dylib. o
o debuginfo combinado resultante é colocado em um diretório ao lado do executável ou
.dylib, mas com a extensão .dSYM.

Com --dsymutil = no, Valgrind detectará casos em que o diretório .dSYM é
ausente ou está presente, mas não parece corresponder ao executável associado ou
.dylib, provavelmente porque está desatualizado. Nestes casos, Valgrind imprimirá um
mensagem de aviso, mas não tome nenhuma ação adicional.

Com --dsymutil = yes, Valgrind irá, em tais casos, executar automaticamente dsymutil como
necessário para atualizar o debuginfo. Para todos os efeitos práticos, se você sempre
usar --dsymutil = yes, então nunca haverá necessidade de executar dsymutil manualmente ou como parte
do sistema de construção de seus aplicativos, uma vez que Valgrind irá executá-lo conforme necessário.

Valgrind não tentará executar dsymutil em qualquer executável ou biblioteca em / usr /,
/ bin /, / sbin /, / opt /, / sw /, / System /, / Library / ou / Applications / já que dsymutil irá
sempre falha em tais situações. Ele falha tanto porque o debuginfo para tal
os componentes do sistema pré-instalados não estão disponíveis em qualquer lugar, e também porque estariam
requerem privilégios de gravação nesses diretórios.

Tenha cuidado ao usar --dsymutil = yes, uma vez que causará .dSYM pré-existente
diretórios a serem excluídos e recriados silenciosamente. Observe também que dsymutil é bastante
lento, às vezes excessivamente.

--max-stackframe = [predefinição: 2000000]
O tamanho máximo de um quadro de pilha. Se o ponteiro da pilha se mover mais do que este valor
então Valgrind assumirá que o programa está mudando para uma pilha diferente.

Você pode precisar usar esta opção se o seu programa tiver grandes matrizes alocadas na pilha.
Valgrind mantém registro do ponteiro de pilha do seu programa. Se mudar em mais do que o
valor limite, Valgrind assume que seu programa está mudando para uma pilha diferente, e
Memcheck se comporta de maneira diferente do que seria para uma mudança de ponteiro de pilha menor do que o
limiar. Normalmente, essa heurística funciona bem. No entanto, se o seu programa aloca grandes
estruturas na pilha, essa heurística será enganada e o Memcheck, subsequentemente,
relatar um grande número de acessos de pilha inválidos. Esta opção permite que você altere o
limite para um valor diferente.

Você só deve considerar o uso desta opção se a saída de depuração do Valgrind direcionar você a
faça isso. Nesse caso, ele informará o novo limite que você deve especificar.

Em geral, alocar grandes estruturas na pilha é uma má ideia, porque você pode
facilmente fica sem espaço de pilha, especialmente em sistemas com memória limitada ou que
espera suportar um grande número de threads, cada um com uma pequena pilha, e também porque
a verificação de erros realizada pelo Memcheck é mais eficaz para dados alocados em heap
do que para dados alocados na pilha. Se você tiver que usar esta opção, você pode querer
considere reescrever seu código para alocar na pilha em vez de na pilha.

--main-stacksize = [predefinição: usar atual 'ulimit' valor]
Especifica o tamanho da pilha do thread principal.

Para simplificar o gerenciamento de memória, Valgrind reserva todo o espaço necessário para o principal
pilha do thread na inicialização. Isso significa que ele precisa saber o tamanho da pilha necessária em
startup

Por padrão, Valgrind usa o valor "ulimit" atual para o tamanho da pilha, ou 16 MB,
o que for menor. Em muitos casos, isso dá um tamanho de pilha na faixa de 8 a 16 MB,
que quase nunca transborda para a maioria dos aplicativos.

Se você precisar de um tamanho total de pilha maior, use --main-stacksize para especificá-lo. Apenas configure-o
tão alto quanto você precisa, desde reservar muito mais espaço do que você precisa (ou seja, centenas
de megabytes a mais do que você precisa) restringe os alocadores de memória do Valgrind e pode
reduzir a quantidade total de memória que o Valgrind pode usar. Isso é apenas de
significado em máquinas de 32 bits.

No Linux, você pode solicitar uma pilha de tamanho de até 2 GB. Valgrind vai parar com um
mensagem de diagnóstico se a pilha não puder ser alocada.

--main-stacksize afeta apenas o tamanho da pilha para o encadeamento inicial do programa. Tem
não influencia o tamanho das pilhas de rosca, pois Valgrind não as aloca.

Você pode precisar usar ambos --main-stacksize e --max-stackframe juntos. Isto é
importante entender isso --main-stacksize define o tamanho máximo total da pilha,
enquanto --max-stackframe especifica o maior tamanho de qualquer quadro de pilha. Você irá
tem que trabalhar o --main-stacksize valor para você (normalmente, se o seu
aplicativos segfaults). Mas Valgrind lhe dirá o necessário --max-stackframe tamanho,
se necessário.

Conforme discutido mais adiante na descrição de --max-stackframe, um requisito para um grande
pilha é um sinal de problemas potenciais de portabilidade. É melhor colocar todos
grandes dados na memória alocada por heap.

--max-threads = [predefinição: 500]
Por padrão, Valgrind pode lidar com até 500 threads. Ocasionalmente, esse número é muito
pequena. Use esta opção para fornecer um limite diferente. Por exemplo, --max-threads = 3000.

MALLOC () - RELACIONADO OPÇÕES

Para ferramentas que usam sua própria versão de malloc (por exemplo, Memcheck, Massif, Helgrind, DRD), o
as seguintes opções se aplicam.

--alignment = [predefinição: 8 or 16, Dependendo on da plataforma]
Por padrão Valgrind's Malloc, realocar, etc, retorna um bloco cujo endereço inicial é
Alinhado com 8 bytes ou alinhado com 16 bytes (o valor depende da plataforma e corresponde ao
padrão da plataforma). Esta opção permite que você especifique um alinhamento diferente. o
valor fornecido deve ser maior ou igual ao padrão, menor ou igual a
4096 e deve ser uma potência de dois.

--redzone-size = [predefinição: depende on da ferramenta]
Valgrind's maloc, realocar, etc, adicione blocos de preenchimento antes e depois de cada bloco de heap
alocado pelo programa em execução. Esses blocos de preenchimento são chamados de zonas vermelhas. o
o valor padrão para o tamanho da zona vermelha depende da ferramenta. Por exemplo, Memcheck adiciona e
protege um mínimo de 16 bytes antes e depois de cada bloco alocado pelo cliente.
Isso permite a detecção de underruns ou overruns de blocos de até 16 bytes.

Aumentar o tamanho da zona vermelha torna possível detectar transbordamentos de distâncias maiores,
mas aumenta a quantidade de memória usada pelo Valgrind. Diminuir o tamanho da zona vermelha
reduz a memória necessária para Valgrind, mas também reduz as chances de detectar
over / underruns, portanto, não é recomendado.

INCOMUM OPÇÕES

Essas opções se aplicam a todas as ferramentas, pois afetam certos trabalhos obscuros do Valgrind
essencial. A maioria das pessoas não precisará usá-los.

--smc-check = [predefinição: tudo não-arquivo for x86 / amd64 / s390x,
pilha for de outros arcos]
Esta opção controla a detecção do Valgrind de código de modificação automática. Se nenhuma verificação for
feito, quando um programa executa algum código, em seguida, o substitui por um novo código, e
executa o novo código, Valgrind continuará a executar as traduções que fez para
o código antigo. Isso provavelmente levará a um comportamento incorreto e / ou travamentos.

Para arquiteturas "modernas" - qualquer coisa que não seja x86, amd64 ou s390x - o padrão
is pilha. Isso ocorre porque um programa correto deve executar uma ação explícita para restabelecer
Coerência do cache DI após modificação do código. Valgrind observa e honra tais
ações, com o resultado que o código de automodificação é tratado de forma transparente com zero
custo extra.

Para x86, amd64 e s390x, o programa não é obrigado a notificar o hardware de
necessária sincronização de coerência DI. Portanto, o padrão é tudo não-arquivo, que cobre o
caso normal de geração de código em uma área de mmap anônima (sem backup de arquivo).

Os significados das quatro configurações disponíveis são os seguintes. Sem detecção (Nenhum),
detectar o código auto-modificador na pilha (que é usado pelo GCC para implementar
funções) (pilha), detecta o código de automodificação em todos os lugares (todos os), e detectar
código de auto-modificação em todos os lugares, exceto em mapeamentos baseados em arquivo (tudo não-arquivo).

Correndo com todos os irá desacelerar Valgrind visivelmente. Correndo com Nenhum raramente
acelerar as coisas, uma vez que muito pouco código é gerado dinamicamente na maioria dos programas.
A Valgrind_discard_translations. a solicitação do cliente é uma alternativa para --smc-check = all
e --smc-check = all-non-file que requer mais esforço do programador, mas permite Valgrind
para executar seu programa mais rápido, dizendo-lhe precisamente quando as traduções precisam ser
refeito.

--smc-check = all-non-file fornece uma versão mais barata, mas mais limitada de
--smc-check = all. Ele adiciona verificações a quaisquer traduções que não se originem de
mapeamentos de memória com suporte de arquivo. Aplicativos típicos que geram código, por exemplo JITs
em navegadores da web, gere código em áreas de mapeamento anônimas, enquanto o código "fixo"
do navegador sempre reside em mapeamentos baseados em arquivo. --smc-check = all-non-file toma
vantagem desta observação, limitando a sobrecarga de verificação de código que é
provavelmente será gerado pelo JIT.

--read-inline-info = [predefinição: Vejo abaixo]
Quando habilitado, Valgrind lerá informações sobre chamadas de função embutidas de DWARF3
informações de depuração. Isso retarda a inicialização do Valgrind e faz com que use mais memória (normalmente para
cada pedaço de código embutido, 6 palavras e espaço para o nome da função), mas resulta
em rastreamentos de pilha mais descritivos. Para a versão 3.10.0, esta funcionalidade está habilitada
por padrão, apenas para destinos Linux, Android e Solaris e apenas para as ferramentas
Memcheck, Helgrind e DRD. Aqui está um exemplo de alguns rastreamentos de pilha com
--read-inline-info = no:

== 15380 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15380 == em 0x80484EA: main (inlinfo.c: 6)
== 15380 ==
== 15380 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15380 == em 0x8048550: fun_noninline (inlinfo.c: 6)
== 15380 == por 0x804850E: principal (inlinfo.c: 34)
== 15380 ==
== 15380 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15380 == em 0x8048520: main (inlinfo.c: 6)

E aqui estão os mesmos erros com --read-inline-info = yes:

== 15377 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15377 == em 0x80484EA: fun_d (inlinfo.c: 6)
== 15377 == por 0x80484EA: fun_c (inlinfo.c: 14)
== 15377 == por 0x80484EA: fun_b (inlinfo.c: 20)
== 15377 == por 0x80484EA: fun_a (inlinfo.c: 26)
== 15377 == por 0x80484EA: main (inlinfo.c: 33)
== 15377 ==
== 15377 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15377 == em 0x8048550: fun_d (inlinfo.c: 6)
== 15377 == por 0x8048550: fun_noninline (inlinfo.c: 41)
== 15377 == por 0x804850E: principal (inlinfo.c: 34)
== 15377 ==
== 15377 == O salto ou movimento condicional depende do (s) valor (es) não inicializado (s)
== 15377 == em 0x8048520: fun_d (inlinfo.c: 6)
== 15377 == por 0x8048520: main (inlinfo.c: 35)

--read-var-info = [predefinição: não]
Quando ativado, Valgrind irá ler informações sobre os tipos de variáveis ​​e localizações de
Informações de depuração DWARF3. Isso retarda a inicialização do Valgrind significativamente e o torna útil
significativamente mais memória, mas para as ferramentas que podem tirar proveito disso (Memcheck,
Helgrind, DRD) pode resultar em mensagens de erro mais precisas. Por exemplo, aqui estão
alguns erros padrão emitidos por Memcheck:

== 15363 == Byte (s) não inicializado (s) encontrado (s) durante a solicitação de verificação do cliente
== 15363 == em 0x80484A9: coaxar (varinfo1.c: 28)
== 15363 == por 0x8048544: main (varinfo1.c: 55)
== 15363 == O endereço 0x80497f7 tem 7 bytes dentro do símbolo de dados "global_i2"
== 15363 ==
== 15363 == Byte (s) não inicializado (s) encontrado (s) durante a solicitação de verificação do cliente
== 15363 == em 0x80484A9: coaxar (varinfo1.c: 28)
== 15363 == por 0x8048550: main (varinfo1.c: 56)
== 15363 == O endereço 0xbea0d0cc está na pilha do thread 1
== 15363 == no quadro # 1, criado por main (varinfo1.c: 45)

E aqui estão os mesmos erros com --read-var-info = yes:

== 15370 == Byte (s) não inicializado (s) encontrado (s) durante a solicitação de verificação do cliente
== 15370 == em 0x80484A9: coaxar (varinfo1.c: 28)
== 15370 == por 0x8048544: main (varinfo1.c: 55)
== 15370 == Localização 0x80497f7 é 0 bytes dentro de global_i2 [7],
== 15370 == uma variável global declarada em varinfo1.c: 41
== 15370 ==
== 15370 == Byte (s) não inicializado (s) encontrado (s) durante a solicitação de verificação do cliente
== 15370 == em 0x80484A9: coaxar (varinfo1.c: 28)
== 15370 == por 0x8048550: main (varinfo1.c: 56)
== 15370 == Localização 0xbeb4a0cc é 0 bytes dentro da var local "local"
== 15370 == declarado em varinfo1.c: 46, no frame # 1 do thread 1

--vgdb-poll = [predefinição: 5000]
Como parte de seu loop principal, o agendador Valgrind fará uma sondagem para verificar se alguma atividade
(como um comando externo ou alguma entrada de um gdb) deve ser tratado pelo gdbserver.
Esta pesquisa de atividade será feita após ter executado o determinado número de blocos básicos (ou
um pouco mais do que o número fornecido de blocos básicos). Esta enquete é muito barata, então o
o valor padrão é definido relativamente baixo. Você pode diminuir ainda mais este valor se vgdb
não pode usar a chamada de sistema ptrace para interromper Valgrind se todos os threads são (a maioria dos
tempo) bloqueado em uma chamada de sistema.

--vgdb-shadow-registers = no | yes [predefinição: não]
Quando ativado, o gdbserver irá expor os registradores sombra Valgrind ao GDB. Com isso,
o valor dos registradores sombra Valgrind pode ser examinado ou alterado usando GDB.
A exposição de registradores sombra funciona apenas com GDB versão 7.1 ou posterior.

--vgdb-prefix = [predefinição: / tmp / vgdb-pipe]
Para se comunicar com gdb / vgdb, o Valgrind gdbserver cria 3 arquivos (2 chamados FIFOs
e um arquivo de memória compartilhada mmap). A opção de prefixo controla o diretório e o prefixo
para a criação desses arquivos.

--run-libc-freeres = [predefinição: sim]
Esta opção é relevante apenas ao executar Valgrind no Linux.

A biblioteca GNU C (libc.so), que é usado por todos os programas, pode alocar memória para
seus próprios usos. Normalmente não se preocupa em liberar essa memória quando o programa termina—
não haveria nenhum ponto, uma vez que o kernel do Linux recupera todos os recursos do processo quando um
o processo sai de qualquer maneira, então só iria desacelerar as coisas.

Os autores da glibc perceberam que esse comportamento causa verificadores de vazamento, como Valgrind,
para relatar vazamentos falsamente na glibc, quando uma verificação de vazamento é feita na saída. A fim de evitar
isso, eles forneceram uma rotina chamada __libc_freeres especificamente para fazer o lançamento glibc
toda a memória alocada. Memcheck, portanto, tenta executar __libc_freeres na saída.

Infelizmente, em algumas versões muito antigas da glibc, __libc_freeres é suficientemente
com erros para causar falhas de segmentação. Isso foi particularmente perceptível no Red Hat 7.1.
Portanto, esta opção é fornecida a fim de inibir a execução de __libc_freeres. Se o seu
programa parece funcionar bem no Valgrind, mas segfaults na saída, você pode achar que
--run-libc-freeres = no corrige isso, embora ao custo de, possivelmente, relatórios falsos
vazamentos de espaço em libc.so.

--sim-hints = hint1, hint2, ...
Passe dicas diversas para Valgrind que modificam ligeiramente o comportamento simulado em
formas não padronizadas ou perigosas, possivelmente para ajudar na simulação de características estranhas. Por
padrão nenhuma dica está habilitada. Use com cuidado! As dicas atualmente conhecidas são:

· lax-ioctls: Seja muito frouxo quanto ao manuseio de ioctl; a única suposição é que o tamanho
está correto. Não requer que o buffer completo seja inicializado durante a gravação.
Sem isso, usar alguns drivers de dispositivo com um grande número de ioctl estranhos
comandos torna-se muito cansativo.

· compatível com fusível: Habilite tratamento especial para certas chamadas de sistema que podem bloquear
em um sistema de arquivos FUSE. Isso pode ser necessário ao executar o Valgrind em um
programa multi-threaded que usa um thread para gerenciar um sistema de arquivos FUSE e
outro segmento para acessar esse sistema de arquivos.

· habilitar externo: Habilite alguma magia especial necessária quando o programa que está sendo executado é
próprio Valgrind.

· sem prefixo interno: Desativar a impressão de um prefixo > na frente de cada stdout ou stderr
linha de saída em um Valgrind interno sendo executado por um Valgrind externo. Isso é útil
ao executar testes de regressão Valgrind em uma configuração externa / interna. Observe que o
prefixo > sempre será impresso na frente das linhas de registro de depuração internas.

· No-NPTL-Pthread-Stackcache: Esta dica é relevante apenas ao executar o Valgrind no
Linux.

A biblioteca GNU glibc pthread (libpthread.so), que é usado por programas pthread,
mantém um cache de pilhas de pthread. Quando um pthread termina, a memória usada
para a pilha pthread e algumas estruturas de dados relacionadas ao armazenamento local da thread não são
sempre lançado diretamente. Esta memória é mantida em um cache (até um certo tamanho),
e é reutilizado se um novo encadeamento for iniciado.

Este cache faz com que a ferramenta helgrind relate alguma condição de corrida falsa positiva
erros nesta memória em cache, pois o helgrind não entende o glibc interno
primitivos de sincronização de cache. Então, ao usar o helgrind, desabilitando o cache
ajuda a evitar condições de corrida falsos positivos, em particular ao usar thread
variáveis ​​de armazenamento local (por exemplo, variáveis ​​usando o __fio qualificador).

Ao usar a ferramenta memcheck, desabilitar o cache garante a memória usada pelo glibc
para lidar com variáveis ​​__thread é liberado diretamente quando um thread termina.

Nota: Valgrind desativa o cache usando algum conhecimento interno da pilha glibc
implementação de cache e examinando as informações de depuração do pthread
biblioteca. Esta técnica é, portanto, um tanto frágil e pode não funcionar para todos os glibc
versões. Isso foi testado com sucesso com várias versões glibc (por exemplo
2.11, 2.16, 2.18) em várias plataformas.

· portas frouxas: (Solaris apenas) Seja muito negligente quanto ao manuseio da escala da porta
descritores de arquivo de porta não reconhecidos. Não requer que o buffer cheio seja
inicializado ao escrever. Sem isso, os programas que usam porta da biblioteca(3LIB) funcionalidade
com semântica totalmente proprietária pode relatar um grande número de falsos positivos.

--fair-sched = [predefinição: não]
A --horário justo opção controla o mecanismo de bloqueio usado pelo Valgrind para serializar
execução de thread. O mecanismo de bloqueio controla a forma como os threads são programados,
e diferentes configurações oferecem diferentes compensações entre justiça e desempenho. Para
mais detalhes sobre o esquema de serialização de thread Valgrind e seu impacto sobre
desempenho e agendamento de thread, consulte Scheduling and Multi-Thread Performance.

· O valor que --fair-sched = yes ativa um programador justo. Em suma, se for múltiplo
os threads estão prontos para serem executados, os threads serão agendados em rodízio.
Este mecanismo não está disponível em todas as plataformas ou versões do Linux. Se não
disponível, usando --fair-sched = yes fará com que o Valgrind termine com um erro.

Você pode descobrir que esta configuração melhora a capacidade de resposta geral se estiver executando um
programa interativo multithread, por exemplo, um navegador da web, em Valgrind.

· O valor que --fair-sched = try ativa o agendamento justo, se disponível na plataforma.
Caso contrário, ele voltará automaticamente para --fair-sched = no.

· O valor que --fair-sched = no ativa um programador que não garante justiça
entre threads prontos para serem executados, mas que em geral oferecem o melhor desempenho.

--kernel-variant = variant1, variant2, ...
Lidar com chamadas de sistema e ioctls decorrentes de variantes menores do kernel padrão para
esta plataforma. Istoéútil para rodar em kernels hackeados ou com módulos de kernel
que suportam ioctls não padronizados, por exemplo. Use com cuidado. Se você não
entenda o que essa opção faz, então você quase certamente não precisa dela. Atualmente
as variantes conhecidas são:

· bproc: apoiar o sys_broc chamada de sistema em x86. Isso é para rodar em BProc,
que é uma variante menor do Linux padrão que às vezes é usado para construir
aglomerados.

· android-no-hw-tls: algumas versões do emulador Android para ARM não fornecem um
registro de hardware TLS (estado de segmento local) e Valgrind trava na inicialização. Usar
esta variante para selecionar suporte de software para TLS.

· android-gpu-sgx5xx: use isso para suportar o manuseio de ioctls proprietários para o
Série PowerVR SGX 5XX de GPUs em dispositivos Android. Deixar de selecionar isto não
causar problemas de estabilidade, mas pode fazer com que o Memcheck relate erros falsos após o
programa executa ioctls específicos da GPU.

· android-gpu-adreno3xx: da mesma forma, use isso para oferecer suporte ao manuseio de propriedade
ioctls para a série Qualcomm Adreno 3XX de GPUs em dispositivos Android.

--merge-recursive-frames = [predefinição: 0]
Alguns algoritmos recursivos, por exemplo, implementações de árvore binária balanceada, criam
muitos rastreamentos de pilha diferentes, cada um contendo ciclos de chamadas. Um ciclo é definido como
dois valores de contador de programa idênticos separados por zero ou mais outros contadores de programa
valores. Valgrind pode então usar muita memória para armazenar todos esses rastreamentos de pilha. Isto é
um uso insuficiente da memória, considerando que tais rastreamentos de pilha contêm repetidas e desinteressantes
chamadas recursivas em vez de informações mais interessantes, como a função que tem
iniciou a chamada recursiva.

A opção --merge-recursive-frames = instrui Valgrind para detectar e mesclar
ciclos de chamadas recursivas com um tamanho de até quadros. Quando esse ciclo é
detectado, Valgrind registra o ciclo no rastreamento de pilha como um contador de programa exclusivo.

O valor 0 (o padrão) não causa mesclagem de chamadas recursivas. Um valor de 1 causará
rastreamentos de pilha de algoritmos recursivos simples (por exemplo, uma implementação fatorial)
a ser recolhido. Um valor de 2 geralmente será necessário para recolher os rastreamentos de pilha produzidos
por algoritmos recursivos, como árvores binárias, classificação rápida, etc. Valores mais altos podem ser
necessário para algoritmos recursivos mais complexos.

Nota: chamadas recursivas são detectadas pela análise dos valores do contador do programa. Eles não são
detectado olhando os nomes das funções.

--num-transtab-setores = [predefinição: 6 for Android plataformas, 16 for todos os outros]
Valgrind traduz e instrumenta o código de máquina do seu programa em pequenos fragmentos
(blocos básicos). As traduções são armazenadas em um cache de tradução que é dividido
em várias seções (setores). Se o cache estiver cheio, o setor que contém o
as traduções mais antigas são esvaziadas e reutilizadas. Se essas traduções antigas forem necessárias novamente,
Valgrind deve traduzir e re-instrumentar o código de máquina correspondente, que é
caro. Se o conjunto de trabalho de "instruções executadas" de um programa for grande, aumentando
o número de setores pode melhorar o desempenho, reduzindo o número de
são necessárias retraduções. Os setores são alocados sob demanda. Uma vez alocado, um setor pode
nunca seja liberado e ocupa um espaço considerável, dependendo da ferramenta e do valor
of --avg-transtab-tamanho da entrada (cerca de 40 MB por setor para Memcheck). Use a opção
--stats = yes para obter informações precisas sobre a memória utilizada por um setor e o
alocação e reciclagem de setores.

--avg-transtab-entry-size = [predefinição: 0, significado usar ferramenta fornecido predefinição]
Tamanho médio do bloco básico traduzido. Este tamanho médio é usado para dimensionar o
tamanho de um setor. Cada ferramenta fornece um valor padrão a ser usado. Se este valor padrão
for muito pequeno, os setores de tradução ficarão cheios muito rapidamente. Se este padrão
valor for muito grande, uma parte significativa da memória do setor de tradução não será utilizada.
Observe que o tamanho médio de uma tradução de bloco básico depende da ferramenta e pode
dependem das opções da ferramenta. Por exemplo, a opção memcheck --track-origins = yes aumenta
o tamanho das traduções do bloco básico. Usar --avg-transtab-tamanho da entrada para sintonizar o
tamanho dos setores, seja para ganhar memória ou para evitar muitas retraduções.

--aspace-minaddr = [predefinição: depende on da plataforma]
Para evitar conflitos potenciais com algumas bibliotecas do sistema, Valgrind não usa o
espaço de endereço abaixo --aspace-minaddr valor, mantendo-o reservado no caso de uma biblioteca
solicita especificamente memória nesta região. Portanto, algum valor "pessimista" é adivinhado
por Valgrind dependendo da plataforma. No Linux, por padrão, Valgrind evita usar o
primeiros 64 MB, mesmo que normalmente não haja conflito nesta zona completa. Você pode usar
a opção --aspace-minaddr para que seu aplicativo com fome de memória se beneficie de
mais dessa memória inferior. Por outro lado, se você encontrar um conflito, aumentando
o valor aspace-minaddr pode resolvê-lo. Os conflitos normalmente se manifestam com
falhas de mmap na faixa inferior do espaço de endereço. O endereço fornecido deve ser página
alinhado e deve ser igual ou maior a 0x1000 (4KB). Para encontrar o valor padrão em seu
plataforma, faça algo como valgrind -d -d data 2> & 1 | grep -i minaddr. Valores
inferiores a 0x10000 (64 KB) são conhecidos por criar problemas em algumas distribuições.

--valgrind-stacksize = [predefinição: 1 MB]
Para cada thread, Valgrind precisa de sua própria pilha 'privada'. O tamanho padrão para estes
pilhas são amplamente dimensionadas e, portanto, devem ser suficientes na maioria dos casos. No caso de
o tamanho for muito pequeno, o Valgrind causará um segfault. Antes do segfaulting, um aviso pode ser
produzido por Valgrind ao se aproximar do limite.

Use a opção --valgrind-stacksize se tal aviso (improvável) for produzido, ou
Valgrind morre devido a uma violação de segmentação. Essas violações de segmentação foram
visto ao remover grandes símbolos C ++.

Se seu aplicativo usa muitos threads e precisa de muita memória, você pode ganhar alguns
memória reduzindo o tamanho dessas pilhas Valgrind usando a opção
--valgrind-stacksize.

--show-emwarns = [predefinição: não]
Quando habilitado, Valgrind emitirá avisos sobre sua emulação de CPU em certos casos.
Geralmente não são interessantes.

--require-text-symbol =: sonamepatt: fnnamepatt
Quando um objeto compartilhado cujo soname corresponde sonampatt é carregado no processo,
examine todos os símbolos de texto que exporta. Se nenhum desses corresponder fnnamepatt, imprima um
mensagem de erro e abandone a execução. Isso torna possível garantir que a execução
não continue a menos que um determinado objeto compartilhado contenha um nome de função específico.

Ambos sonampatt e fnnamepatt pode ser escrito usando o usual ? e * curingas. Para
exemplo: ": * libc.so *: foo? bar". Você pode usar caracteres diferentes de dois-pontos para separar
os dois padrões. É importante apenas que o primeiro caractere e o separador
personagem são os mesmos. Por exemplo, o exemplo acima também pode ser escrito
"Q * libc.so * Qfoo? Bar". Múltiplo
--require-texto-símbolo sinalizadores são permitidos, caso em que objetos compartilhados que são carregados
no processo será verificado em relação a todos eles.

O objetivo disso é oferecer suporte ao uso confiável de bibliotecas marcadas. Por exemplo,
suponha que temos uma versão do GCC's libgomp.so que foi marcado com
anotações para apoiar Helgrind. É muito fácil e confuso carregar o errado,
não anotado libgomp.so no aplicativo. Portanto, a ideia é: adicionar um símbolo de texto no
biblioteca marcada, por exemplo anotado_para_helgrind_3_6, e então dar a bandeira
--require-text-symbol =: * libgomp * so *: annotated_for_helgrind_3_6 para que quando libgomp.so
é carregado, Valgrind verifica sua tabela de símbolos, e se o símbolo não estiver presente, a execução é
abortado, em vez de continuar silenciosamente com a biblioteca não marcada. Observe que você
deve colocar toda a bandeira entre aspas para evitar que os shells expandam o * e ?
curingas.

--soname-sinônimos = syn1 = pattern1, syn2 = pattern2, ...
Quando uma biblioteca compartilhada é carregada, Valgrind verifica as funções na biblioteca que
deve ser substituído ou embalado. Por exemplo, Memcheck substitui todos os malloc relacionados
funções (malloc, free, calloc, ...) com suas próprias versões. Essas substituições são
feito por padrão apenas em bibliotecas compartilhadas cujo soname corresponde a um soname predefinido
padrão (por exemplo libc.so * no Linux). Por padrão, nenhuma substituição é feita para um estaticamente
biblioteca vinculada ou para bibliotecas alternativas, como tcmalloc. Em alguns casos, o
substituições permitem --sonome-sinônimos para especificar um padrão de sinônimo adicional, dando
flexibilidade na reposição.

Atualmente, essa flexibilidade só é permitida para as funções relacionadas ao malloc, usando
o sinônimo Somalloc. Este sinônimo pode ser usado para todas as ferramentas que fazem a substituição padrão
de funções relacionadas a malloc (por exemplo, memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Biblioteca malloc alternativa: para substituir as funções relacionadas ao malloc em uma alternativa
biblioteca com soname mymalloclib.so, dê a opção
--soname-sinônimos = somalloc = mymalloclib.so. Um padrão pode ser usado para combinar vários
bibliotecas sonames. Por exemplo, --soname-sinônimos = somalloc = * tcmalloc * vai combinar
o soname de todas as variantes da biblioteca tcmalloc (nativa, depuração, perfilada, ...
variantes tcmalloc).

Nota: o soname de uma biblioteca compartilhada de elfo pode ser recuperado usando o readelf
utilidade.

· As substituições em uma biblioteca vinculada estaticamente são feitas usando o NENHUM padrão.
Por exemplo, se você ligar com libtcmalloc.a, o memcheck funcionará corretamente quando você
dê a opção --soname-sinônimos = somalloc = NENHUMA. Observe que um padrão NENHUM irá
coincidir com o executável principal e qualquer biblioteca compartilhada sem soname.

· Para executar uma versão "padrão" do Firefox para Linux, na qual JEMalloc está vinculado ao
executável principal, use --soname-sinônimos = somalloc = NENHUMA.

DEPURAÇÃO VALGRIND OPÇÕES

Existem também algumas opções para depurar o próprio Valgrind. Você não deve precisar usá-los
no andamento normal das coisas. Se você deseja ver a lista, use o --help-depurar opção.

VERIFICAÇÃO DE MEMÓRIA OPÇÕES

--leak-check = [predefinição: resumo]
Quando ativado, pesquisa por vazamentos de memória quando o programa cliente terminar. Se definido para
resumo, diz quantos vazamentos ocorreram. Se definido para cheio or sim, cada vazamento individual
será mostrado em detalhes e / ou contado como um erro, conforme especificado pelas opções
- mostrar-tipos de vazamento e --errors-para-tipos de vazamento.

--leak-resolution = [predefinição: Alto]
Ao fazer a verificação de vazamentos, determina o quanto o Memcheck está disposto a considerar diferentes
backtraces para ser o mesmo para fins de mesclar vários vazamentos em um único
relatório de vazamento. Quando definido para baixo, apenas as duas primeiras entradas precisam corresponder. Quando med, quatro
as entradas têm que corresponder. Quando Alto, todas as entradas precisam corresponder.

Para depuração de vazamento hardcore, você provavelmente deseja usar - resolução de vazamento = alta juntos
com --num-callers = 40 ou algum número tão grande.

Observe que o - resolução de vazamento configuração não afeta a capacidade do Memcheck de encontrar
vazamentos. Isso apenas muda a forma como os resultados são apresentados.

--mostrar-vazar-tipos = [predefinição: definitiva, possível]
Especifica os tipos de vazamento para mostrar em um cheio pesquisa de vazamento, de uma das seguintes maneiras:

· Uma lista separada por vírgulas de um ou mais dos definido indireto possível alcançável.

· todos os para especificar o conjunto completo (todos os tipos de vazamento). É equivalente a
--show-vazamento-tipos = definitivo, indireto, possível, alcançável.

· Nenhum para o conjunto vazio.

--errors-para-vazamento-tipos = [predefinição: definitiva, possível]
Especifica os tipos de vazamento para contar como erros em um cheio busca de vazamento. o is
especificado de forma semelhante a - mostrar-tipos de vazamento

--leak-check-heuristics = [predefinição: tudo]
Especifica o conjunto de heurísticas de verificação de vazamento a ser usado durante as pesquisas de vazamento. o
heurísticas controlam quais ponteiros internos para um bloco fazem com que ele seja considerado como
alcançável. O conjunto heurístico é especificado de uma das seguintes maneiras:

· Uma lista separada por vírgulas de um ou mais dos cadeia padrão comprimento 64 nova matriz
herança múltipla.

· todos os para ativar o conjunto completo de heurísticas. É equivalente a
--leak-check-heuristics = stdstring, length64, newarray, herança múltipla.

· Nenhum para o conjunto vazio.

Observe que essas heurísticas dependem do layout dos objetos produzidos pelo
Compilador C ++. Eles foram testados com algumas versões do gcc (por exemplo, 4.4 e 4.7). Elas
pode não funcionar corretamente com outros compiladores C ++.

--show-reachable = , --show-possivelmente-perdido =
Essas opções fornecem uma maneira alternativa de especificar os tipos de vazamento a serem mostrados:

· --show-reachable = no --mostrar-possivelmente-perdido = sim é equivalente a
--show-vazamento-tipos = definitivo, possível.

· --show-reachable = no --mostrar-possivelmente-perdido = não é equivalente a
--show-vazamento-tipos = definitivo.

· --show-reachable = yes é equivalente a --mostrar-vazar-tipos = todos.

Observe que --mostrar-possivelmente-perdido = não não tem efeito se --show-reachable = yes é especificado.

--undef-value-errors = [predefinição: sim]
Controla se o Memcheck relata o uso de erros de valor indefinido. Defina isso para não if
você não quer ver erros de valor indefinido. Também tem o efeito colateral de excesso de velocidade
até Memcheck um pouco.

--track-origins = [predefinição: não]
Controla se o Memcheck rastreia a origem dos valores não inicializados. Por padrão,
não, o que significa que embora possa dizer que um valor não inicializado é
sendo usado de forma perigosa, não pode dizer a você de onde veio o valor não inicializado
a partir de. Isso geralmente torna difícil rastrear a raiz do problema.

Quando definido para sim, Memcheck rastreia as origens de todos os valores não inicializados.
Então, quando um erro de valor não inicializado é relatado, o Memcheck tentará mostrar o
origem do valor. Uma origem pode ser um dos quatro lugares a seguir: um bloco de heap,
uma alocação de pilha, uma solicitação do cliente ou outras fontes diversas (por exemplo, uma chamada para
brk).

Para valores não inicializados originados de um bloco de heap, Memcheck mostra onde o bloco
foi alocado. Para valores não inicializados originados de uma alocação de pilha, Memcheck
pode dizer a qual função alocou o valor, mas não mais do que isso - normalmente
mostra a localização de origem da chave de abertura da função. Então você deveria
verifique cuidadosamente se todas as variáveis ​​locais da função foram inicializadas corretamente.

Sobrecarga de desempenho: o rastreamento da origem é caro. Ele reduz pela metade a velocidade do Memcheck e
aumenta o uso de memória em um mínimo de 100 MB e possivelmente mais. No entanto, pode
reduzir drasticamente o esforço necessário para identificar a causa raiz de não inicializados
erros de valor, e muitas vezes é uma vitória da produtividade do programador, apesar de executar mais
lentamente.

Precisão: o Memcheck rastreia as origens com bastante precisão. Para evitar espaço e tempo muito grandes
overheads, algumas aproximações são feitas. É possível, embora improvável, que
Memcheck relatará uma origem incorreta ou não será capaz de identificar qualquer origem.

Observe que a combinação --track-origins = yes e --undef-value-errors = no is
sem sentido. Memcheck verifica e rejeita esta combinação na inicialização.

--partial -load-ok = [predefinição: sim]
Controla como o Memcheck lida com cargas alinhadas naturalmente de 32, 64, 128 e 256 bits de
endereços para os quais alguns bytes são endereçáveis ​​e outros não. Quando sim, tal
carregamentos não produzem um erro de endereço. Em vez disso, os bytes carregados originados de ilegal
endereços são marcados como não inicializados, e aqueles correspondentes a endereços legais são
tratada da maneira normal.

Quando não, cargas de endereços parcialmente inválidos são tratadas da mesma forma que cargas de
endereços completamente inválidos: um erro de endereço ilegal é emitido e o resultado
bytes são marcados como inicializados.

Observe que o código que se comporta dessa forma viola os padrões ISO C / C ++,
e deve ser considerado quebrado. Se possível, esse código deve ser corrigido.

--expensive-definedness-checks = [predefinição: não]
Controla se o Memcheck deve ser mais preciso, mas também mais caro (tempo
consumindo) algoritmos ao verificar a definição de um valor. A configuração padrão é
não fazer isso e geralmente é suficiente. No entanto, para código altamente otimizado
valgrind pode às vezes reclamar incorretamente. Invocando valgrind com
--expensive-definedness-checks = yes ajuda, mas tem um custo de desempenho. Tempo de execução
degradação de 25% foi observada, mas o custo extra depende muito do
aplicação em mãos.

--keep-stacktraces = alloc | free | alloc-and-free | alloc-then-free | nenhum [predefinição:
alocar-e-livre]
Controla quais rastros de pilha devem ser mantidos para blocos malocalizados e / ou liberados.

Com alocar-então-livre, um rastreamento de pilha é registrado no momento da alocação e está associado
com o bloco. Quando o bloco é liberado, um segundo rastreamento de pilha é registrado, e este
substitui o rastreamento de pilha de alocação. Como resultado, quaisquer erros de "uso após livre" relacionados
para este bloco só pode mostrar um rastreamento de pilha de onde o bloco foi liberado.

Com alocar-e-livre, ambos os rastreamentos de pilha de alocação e desalocação para o bloco
são armazenados. Portanto, um erro "usar após livre" mostrará ambos, o que pode fazer com que o erro
mais fácil de diagnosticar. Comparado com alocar-então-livre, esta configuração aumenta ligeiramente
O uso de memória do Valgrind como o bloco contém duas referências em vez de uma.

Com alocar, apenas o rastreamento de pilha de alocação é registrado (e relatado). Com sem,
apenas o rastreamento de pilha de desalocação é registrado (e relatado). Esses valores um tanto
diminuir a memória do Valgrind e o uso da CPU. Eles podem ser úteis dependendo do erro
tipos que você está procurando e o nível de detalhe necessário para analisá-los. Para
exemplo, se você está interessado apenas em erros de vazamento de memória, é suficiente registrar
os rastreamentos de pilha de alocação.

Com Nenhum, nenhum rastreamento de pilha é registrado para as operações malloc e free. Se seu
programa aloca muitos blocos e / ou aloca / libera de muitas pilhas diferentes
rastreios, isso pode diminuir significativamente a CPU e / ou a memória necessária. Claro, poucos
detalhes serão relatados para erros relacionados aos blocos de heap.

Observe que, uma vez que um rastreamento de pilha é registrado, Valgrind mantém o rastreamento de pilha na memória
mesmo que não seja referenciado por nenhum bloco. Alguns programas (por exemplo, recursivo
algoritmos) pode gerar um grande número de rastreamentos de pilha. Se Valgrind usa muito
memória em tais circunstâncias, você pode reduzir a memória necessária com as opções
--keep-stacktraces e / ou usando um valor menor para a opção --num-chamadores.

--freelist-vol = [predefinição: 20000000]
Quando o programa cliente libera memória usando sem (em C) ou excluir (C ++), essa memória
não é imediatamente disponibilizado para reatribuição. Em vez disso, está marcado
inacessível e colocado em uma fila de blocos liberados. O objetivo é adiar enquanto
possível, o ponto em que a memória liberada volta a circular. Esse
aumenta a chance de o Memcheck ser capaz de detectar acessos inválidos a bloqueios
por um período significativo de tempo depois de serem libertados.

Esta opção especifica o tamanho total máximo, em bytes, dos blocos na fila.
O valor padrão é vinte milhões de bytes. Aumentar isso aumenta o valor total
de memória usada pelo Memcheck, mas pode detectar usos inválidos de blocos liberados que poderiam
caso contrário, não será detectado.

--freelist-big-blocks = [predefinição: 1000000]
Ao disponibilizar blocos da fila de blocos liberados para realocação,
Memcheck irá, em prioridade, recircular os blocos com um tamanho maior ou igual a
--freelist-grandes blocos. Isso garante que a liberação de grandes blocos (em particular a liberação
blocos maiores que --freelist-vol) não leva imediatamente a uma recirculação de
todos (ou muitos) os pequenos blocos na lista livre. Em outras palavras, esta opção
aumenta a probabilidade de descobrir ponteiros pendentes para os blocos "pequenos", mesmo
quando grandes blocos são liberados.

Definir um valor de 0 significa que todos os blocos são recirculados em uma ordem FIFO.

--workaround-gcc296-bugs = [predefinição: não]
Quando ativado, assume que lê e escreve a uma pequena distância abaixo do ponteiro da pilha
são devidos a bugs no GCC 2.96 e não os relata. A "pequena distância" é 256
bytes por padrão. Observe que GCC 2.96 é o compilador padrão em alguns Linux antigos
distribuições (RedHat 7.X) e, portanto, você pode precisar usar esta opção. Não use se
você não precisa fazer isso, pois isso pode fazer com que erros reais sejam esquecidos. Uma alternativa melhor
é usar um GCC mais recente no qual esse bug foi corrigido.

Você também pode precisar usar esta opção ao trabalhar com GCC 3.X ou 4.X em 32 bits
PowerPC Linux. Isso ocorre porque o GCC gera código que ocasionalmente acessa abaixo
o ponteiro da pilha, particularmente para conversões de ponto flutuante de / para inteiros. Esse
viola a especificação PowerPC ELF de 32 bits, que não prevê
locais abaixo do ponteiro da pilha para serem acessíveis.

--show-mismatched-frees = [predefinição: sim]
Quando ativado, o Memcheck verifica se os blocos de heap são desalocados usando uma função que
corresponde à função de alocação. Ou seja, espera sem para ser usado para desalocar
blocos alocados por Malloc, excluir para blocos alocados por novo e excluir[] for
blocos alocados por novo[]. Se uma incompatibilidade for detectada, um erro será relatado. Isto está em
geral importante porque em alguns ambientes, liberando com uma função não correspondente
pode causar travamentos.

No entanto, existe um cenário em que tais incompatibilidades não podem ser evitadas. É quando o
o usuário fornece implementações de novo/novo[] essa ligação Malloc e de excluir/excluir[]
essa ligação sem, e essas funções são alinhadas assimetricamente. Por exemplo, imagine
que excluir[] é inline, mas novo[] não é. O resultado é que Memcheck "vê" todos
excluir[] chamadas como chamadas diretas para sem, mesmo quando a fonte do programa não contém
chamadas incompatíveis.

Isso causa muitos relatórios de erros confusos e irrelevantes.
--show-mismatched-frees = no desativa essas verificações. Geralmente não é aconselhável
desative-os, porém, porque você pode perder erros reais como resultado.

--ignore-ranges = 0xPP-0xQQ [, 0xRR-0xSS]
Quaisquer intervalos listados nesta opção (e vários intervalos podem ser especificados, separados por
vírgulas) serão ignoradas pela verificação de endereçamento de Memcheck.

--malloc-fill =
Preenche blocos alocados por malloc, new, etc, mas não por calloc, com o especificado
byte. Isso pode ser útil ao tentar resolver problemas obscuros de corrupção de memória.
A área alocada ainda é considerada pelo Memcheck como indefinida - somente esta opção
afeta seu conteúdo. Observe que --malloc-fill não afeta um bloco de memória quando
é usado como argumento para solicitações de clientes VALGRIND_MEMPOOL_ALLOC ou
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill =
Preenche blocos liberados por free, delete, etc, com o valor de byte especificado. Isso pode ser
útil ao tentar resolver problemas obscuros de corrupção de memória. A área liberada é
ainda considerado pelo Memcheck como inválido para acesso - esta opção afeta apenas o seu
conteúdo. Observe que --preenchimento livre não afeta um bloco de memória quando é usado como
argumento para pedidos de cliente VALGRIND_MEMPOOL_FREE ou VALGRIND_FREELIKE_BLOCK.

CACHEGRIND OPÇÕES

--I1 = , , tamanho>
Especifique o tamanho, a associatividade e o tamanho da linha do cache de instrução de nível 1.

--D1 = , , tamanho>
Especifique o tamanho, a associatividade e o tamanho da linha do cache de dados de nível 1.

--LL = , , tamanho>
Especifique o tamanho, a associatividade e o tamanho da linha do cache de último nível.

--cache-sim = não | sim [sim]
Habilita ou desabilita a coleta de acesso ao cache e contagens de erros.

--branch-sim = não | sim [não]
Habilita ou desabilita a coleta de instrução de desvio e contagens de predição incorreta. Por
por padrão, isso é desabilitado, pois retarda o Cachegrind em aproximadamente 25%. Observe que
você não pode especificar --cache-sim = no e --branch-sim = no juntos, pois isso iria sair
Cachegrind sem informações para coletar.

--cachegrind-out-file =
Grave os dados do perfil no arquivo em vez de no arquivo de saída padrão,
cachegrind.out. . o %p e %q especificadores de formato podem ser usados ​​para incorporar o processo
ID e / ou o conteúdo de uma variável de ambiente no nome, como é o caso do
opção central --arquivo de log.

CHAMADA GRIND OPÇÕES

--callgrind-out-file =
Grave os dados do perfil no arquivo em vez de no arquivo de saída padrão,
callgrind.out. . o %p e %q especificadores de formato podem ser usados ​​para incorporar o processo
ID e / ou o conteúdo de uma variável de ambiente no nome, como é o caso do
opção central --arquivo de log. Quando vários despejos são feitos, o nome do arquivo é modificado
avançar; Veja abaixo.

--dump-line = [predefinição: sim]
Isso especifica que a contagem de eventos deve ser realizada na granularidade da linha de origem.
Isto permite a anotação de fontes para fontes que são compiladas com informações de depuração
(-g).

--dump-instr = [predefinição: não]
Isso especifica que a contagem de eventos deve ser realizada na granularidade por instrução.
Isso permite a anotação do código de montagem. Atualmente, os resultados só podem ser exibidos
por KCachegrind.

--compress-strings = [predefinição: sim]
Esta opção influencia o formato de saída dos dados do perfil. Ele especifica se
strings (nomes de arquivos e funções) devem ser identificados por números. Isso diminui o
arquivo, mas torna mais difícil para humanos ler (o que não é recomendado em qualquer
caso).

--compress-pos = [predefinição: sim]
Esta opção influencia o formato de saída dos dados do perfil. Ele especifica se
as posições numéricas são sempre especificadas como valores absolutos ou podem ser
em relação aos números anteriores. Isso reduz o tamanho do arquivo.

--combine-dumps = [predefinição: não]
Quando ativado, quando várias partes de dados de perfil devem ser geradas, essas partes são
anexado ao mesmo arquivo de saída. Não recomendado.

--dump-every-bb = [predefinição: 0, nunca]
Despejar dados de perfil a cada contar blocos básicos. Se um despejo é necessário é apenas verificado
quando o agendador interno do Valgrind é executado. Portanto, a configuração mínima útil é
cerca de 100000. A contagem é um valor de 64 bits para possibilitar longos períodos de despejo.

--dump-before =
Despejar ao entrar função.

--zero-before =
Zere todos os custos ao entrar função.

--dump-after =
Despejar ao sair função.

--instr-atstart = [predefinição: sim]
Especifique se deseja que o Callgrind inicie a simulação e criação de perfil desde o início de
o programa. Quando definido como não, o Callgrind não será capaz de coletar nenhuma informação,
incluindo chamadas, mas terá no máximo uma desaceleração em torno de 4, que é o mínimo
Valgrind sobrecarga. A instrumentação pode ser ativada interativamente via callgrind_control
-eu vou.

Observe que o gráfico de chamadas resultante provavelmente não conterá principal, mas irá
contém todas as funções executadas depois que a instrumentação foi habilitada. Instrumentação
também pode ser ativado / desativado programaticamente. Veja o arquivo Callgrind include callgrind.h
para a macro que você deve usar em seu código-fonte.

Para simulação de cache, os resultados serão menos precisos ao ligar a instrumentação
mais tarde na execução do programa, pois o simulador começa com um cache vazio naquele momento.
Ative a coleta de eventos mais tarde para lidar com esse erro.

--collect-atstart = [predefinição: sim]
Especifique se a coleta de eventos está ativada no início da execução do perfil.

Para ver apenas partes do seu programa, você tem duas possibilidades:

1. Zere os contadores de eventos antes de entrar na parte do programa que você deseja traçar o perfil e despeje
os contadores de eventos para um arquivo depois de sair dessa parte do programa.

2. Ligue / desligue o estado de coleta conforme necessário para ver apenas os contadores de eventos acontecendo
enquanto estiver dentro da parte do programa que você deseja traçar.

A segunda opção pode ser usada se a parte do programa que você deseja traçar é chamada de muitos
vezes. A opção 1, ou seja, criar muitos dumps não é prática aqui.

O estado da coleção pode ser alternado na entrada e saída de uma determinada função com a opção
--toggle-coletar. Se você usar esta opção, o estado de coleta deve ser desabilitado no
começo. Observe que a especificação de --toggle-coletar define implicitamente
--collect-state = no.

O estado da coleção também pode ser alternado inserindo a solicitação do cliente
CALLGRIND_TOGGLE_COLLECT; nas posições de código necessárias.

--toggle-collect =
Alternar coleção na entrada / saída de função.

--collect-jumps = [predefinição: não]
Isso especifica se as informações para saltos (condicionais) devem ser coletadas. Como
acima, callgrind_annotate atualmente não é capaz de mostrar os dados. Você tem que usar
KCachegrind para obter setas de salto no código anotado.

--collect-systime = [predefinição: não]
Isso especifica se as informações para horários de chamadas do sistema devem ser coletadas.

--collect-bus = [predefinição: não]
Isso especifica se o número de eventos de barramento global executados deve ser coletado.
O tipo de evento "Ge" é usado para esses eventos.

--cache-sim = [predefinição: não]
Especifique se deseja fazer simulação de cache completa. Por padrão, apenas a instrução lê
os acessos serão contabilizados (“Ir”). Com a simulação de cache, outros contadores de eventos são
habilitado: perda de cache em leituras de instrução ("I1mr" / "ILmr"), acessos de leitura de dados ("Dr")
e perdas de cache relacionadas ("D1mr" / "DLmr"), acessos de gravação de dados ("Dw") e cache relacionado
faltas ("D1mw" / "DLmw"). Para obter mais informações, consulte Cachegrind: a cache and branch-
profiler de previsão.

--branch-sim = [predefinição: não]
Especifique se deseja fazer simulação de previsão de ramificação. Outros contadores de eventos são
habilitado: Número de desvios condicionais executados e erros de preditor relacionados
("Bc" / "Bcm"), executou saltos indiretos e erros relacionados do preditor de endereço de salto
("Bi" / "Bim").

HELGRIND OPÇÕES

--free-is-write = no | yes [predefinição: não]
Quando ativado (não o padrão), Helgrind trata a liberação de memória heap como se o
a memória foi escrita imediatamente antes do livre. Isso expõe corridas onde a memória está
referenciado por um segmento e liberado por outro, mas não há nenhum observável
evento de sincronização para garantir que a referência aconteça antes do gratuito.

Esta funcionalidade é nova no Valgrind 3.7.0 e é considerada experimental. Isto é
não habilitado por padrão porque sua interação com alocadores de memória personalizados não é
bem compreendido no momento. O feedback do usuário é bem-vindo.

--track-lockorders = não | sim [predefinição: sim]
Quando ativado (o padrão), Helgrind executa a verificação de consistência da ordem de bloqueio. Para
alguns programas com erros, o grande número de erros de ordem de bloqueio relatados pode se tornar
irritante, especialmente se você estiver interessado apenas em erros de corrida. Você pode, portanto,
achar útil desabilitar a verificação de ordem de bloqueio.

--history-level = none | aprox | full [predefinição: cheio]
--history-level = full (o padrão) faz com que Helgrind colete informações suficientes sobre
acessos "antigos" que podem produzir dois rastreamentos de pilha em um relatório de corrida - ambos
trace para o acesso atual e o trace para o acesso conflitante mais antigo. Para
limitar o uso de memória, rastreamentos de pilha de acessos "antigos" são limitados a um máximo de 8 entradas,
mesmo se --num-chamadores o valor é maior.

Coletar essas informações é caro em velocidade e memória, especialmente para
programas que fazem muitos eventos de sincronização entre threads (bloqueios, desbloqueios, etc).
Sem essas informações, é mais difícil rastrear as causas raízes das raças.
No entanto, você pode não precisar dele em situações em que deseja apenas verificar o
presença ou ausência de raças, por exemplo, ao fazer o teste de regressão de um
programa anteriormente sem corrida.

--history-level = none é o extremo oposto. Faz com que Helgrind não colete nenhum
informações sobre acessos anteriores. Isso pode ser muito mais rápido do que
--history-level = full.

- nível de história = aprox. fornece um meio-termo entre esses dois extremos. Causa
Helgrind para mostrar um traço completo para o acesso posterior e informações aproximadas
em relação ao acesso anterior. Essas informações aproximadas consistem em duas pilhas e
o acesso anterior tem a garantia de ter ocorrido em algum lugar entre os pontos do programa
denotado pelas duas pilhas. Isso não é tão útil quanto mostrar a pilha exata para o
acesso anterior (como --history-level = full faz), mas é melhor do que nada, e
é quase tão rápido quanto --history-level = none.

--conflict-cache-size = N [predefinição: 1000000]
Este sinalizador só tem efeito em --history-level = full.

As informações sobre acessos conflitantes "antigos" são armazenadas em um cache de tamanho limitado,
com gerenciamento de estilo LRU. Isso é necessário porque não é prático armazenar um
rastreamento de pilha para cada acesso à memória feito pelo programa. Informação histórica
em locais não acessados ​​recentemente é descartado periodicamente, para liberar espaço no
cache.

Esta opção controla o tamanho do cache, em termos do número de diferentes memórias
endereços para os quais informações de acesso conflitantes são armazenadas. Se você encontrar isso
Helgrind está mostrando erros de corrida com apenas uma pilha em vez das duas esperadas
pilhas, tente aumentar este valor.

O valor mínimo é 10,000 e o máximo é 30,000,000 (trinta vezes o padrão
valor). Aumentar o valor em 1 aumenta o requisito de memória de Helgrind em muito
cerca de 100 bytes, então o valor máximo consumirá facilmente três gigabytes extras ou mais
de memória.

--check-stack-refs = no | yes [predefinição: sim]
Por padrão, o Helgrind verifica todos os acessos à memória de dados feitos por seu programa. Esta bandeira
permite que você ignore a verificação de acessos às pilhas de threads (variáveis ​​locais). Isso pode
melhorar o desempenho, mas tem o custo de perder corridas nos dados alocados na pilha.

--ignore-thread-creation = [predefinição: não]
Controla se todas as atividades durante a criação do encadeamento devem ser ignoradas. Por padrão
habilitado apenas no Solaris. Solaris oferece maior rendimento, paralelismo e
escalabilidade do que outros sistemas operacionais, ao custo de um bloqueio mais refinado
atividade. Isso significa, por exemplo, que quando um thread é criado na glibc, apenas um
big lock é usado para todas as configurações de thread. Solaris libc usa vários bloqueios de baixa granularidade
e o thread do criador retoma suas atividades o mais rápido possível, deixando, por exemplo,
pilha e sequência de configuração de TLS para o encadeamento criado. Esta situação confunde Helgrind
uma vez que assume que existe alguma ordem falsa entre o criador e o criado
fio; e, portanto, muitos tipos de condições de corrida no aplicativo não seriam
relatado. Para evitar essa ordem falsa, esta opção de linha de comando é definida como sim por
padrão no Solaris. Todas as atividades (carregamentos, armazenamentos, solicitações de clientes) são, portanto, ignoradas
no decorrer:

· Chamada pthread_create () no thread do criador

· Fase de criação de thread (configuração de pilha e TLS) no thread criado

Além disso, a nova memória alocada durante a criação do thread não é rastreada, ou seja, relatório de corrida
é suprimido lá. O DRD faz a mesma coisa implicitamente. Isso é necessário porque
Solaris libc armazena em cache muitos objetos e os reutiliza para diferentes threads e que
confunde Helgrind.

DRD OPÇÕES

--check-stack-var = [predefinição: não]
Controla se o DRD detecta corridas de dados nas variáveis ​​da pilha. Verificando as variáveis ​​da pilha
está desabilitado por padrão porque a maioria dos programas não compartilham variáveis ​​de pilha sobre
tópicos.

--exclusive-threshold = [predefinição: fora]
Imprime uma mensagem de erro se qualquer mutex ou bloqueio de gravador foi retido por mais tempo
especificado em milissegundos. Esta opção permite a detecção de contenção de bloqueio.

--join-list-vol = [predefinição: 10]
Corridas de dados que ocorrem entre uma instrução no final de um thread e outro thread
pode ser perdido se a informação de acesso à memória for descartada imediatamente após um tópico
foi juntado. Esta opção permite que se especifique para quantos threads unidos a memória
as informações de acesso devem ser retidas.

--primeira corrida apenas = [predefinição: não]
Se deve relatar apenas a primeira corrida de dados que foi detectada em um local da memória
ou todas as corridas de dados que foram detectadas em um local da memória.

--free-is-write = [predefinição: não]
Seja para relatar corridas entre acessar a memória e liberar memória. Habilitando isto
a opção pode fazer com que o DRD funcione um pouco mais devagar. Notas:

· Não habilite esta opção ao usar alocadores de memória personalizados que usam o
VG_USERREQ__MALLOCLIKE_BLOCK e VG_USERREQ__FREELIKE_BLOCK porque isso seria
resultar em falsos positivos.

· Não habilite esta opção ao usar objetos contados por referência porque isso irá
resultar em falsos positivos, mesmo quando esse código foi anotado corretamente com
ANNOTATE_HAPPENS_BEFORE e ANNOTATE_HAPPENS_AFTER. Veja, por exemplo, a saída do
seguinte comando para um exemplo: valgrind --tool = drd --free-is-write = yes
drd / tests / annotate_smart_pointer.

--report-signal-unlocked = [predefinição: sim]
Se relatar chamadas para pthread_cond_signal. e pthread_cond_broadcast onde o
mutex associado ao sinal por meio de pthread_cond_wait or
pthread_cond_timed_waitnão está bloqueado no momento em que o sinal é enviado. Enviando um sinal
sem segurar o bloqueio no mutex associado é um erro de programação comum que pode
causar condições de corrida sutis e comportamento imprevisível. Existem alguns incomuns
padrões de sincronização, no entanto, onde é seguro enviar um sinal sem segurar um
bloquear o mutex associado.

--segment-merging = [predefinição: sim]
Controla a fusão de segmentos. A fusão de segmentos é um algoritmo para limitar o uso de memória do
algoritmo de detecção de corrida de dados. Desativar a mesclagem de segmentos pode melhorar a precisão de
os chamados 'outros segmentos' exibidos em relatórios de corrida, mas também podem desencadear um
de erro de memória.

--segment-merging-interval = [predefinição: 10]
Realize a mesclagem de segmentos somente após o número especificado de novos segmentos ter sido
criada. Esta é uma opção de configuração avançada que permite escolher se deseja
minimizar o uso de memória do DRD escolhendo um valor baixo ou permitir que o DRD funcione mais rápido
escolhendo um valor ligeiramente mais alto. O valor ideal para este parâmetro depende do
programa em análise. O valor padrão funciona bem para a maioria dos programas.

--shared-threshold = [predefinição: fora]
Imprime uma mensagem de erro se o bloqueio do leitor foi mantido por mais tempo do que o tempo especificado
(em milissegundos). Esta opção permite a detecção de contenção de bloqueio.

--show-confl-seg = [predefinição: sim]
Mostrar segmentos conflitantes em relatórios de corrida. Uma vez que esta informação pode ajudar a encontrar o
causa de uma corrida de dados, esta opção é habilitada por padrão. Desativar esta opção torna
a saída de DRD mais compacta.

--show-stack-usage = [predefinição: não]
Imprimir o uso da pilha no tempo de saída do encadeamento. Quando um programa cria um grande número de
threads torna-se importante limitar a quantidade de memória virtual alocada para
pilhas de fios. Esta opção torna possível observar quanta memória stack foi usada
usado por cada thread do programa cliente. Nota: a própria ferramenta DRD aloca alguns
dados temporários na pilha de encadeamentos do cliente. O espaço necessário para estes dados temporários
deve ser alocado pelo programa cliente quando ele aloca a memória da pilha, mas não é
incluído no uso da pilha relatado pelo DRD.

--ignore-thread-creation = [predefinição: não]
Controla se todas as atividades durante a criação do encadeamento devem ser ignoradas. Por padrão
habilitado apenas no Solaris. Solaris oferece maior rendimento, paralelismo e
escalabilidade do que outros sistemas operacionais, ao custo de um bloqueio mais refinado
atividade. Isso significa, por exemplo, que quando um thread é criado na glibc, apenas um
big lock é usado para todas as configurações de thread. Solaris libc usa vários bloqueios de baixa granularidade
e o thread do criador retoma suas atividades o mais rápido possível, deixando, por exemplo,
pilha e sequência de configuração de TLS para o encadeamento criado. Esta situação confunde DRD porque
assume que há alguma ordem falsa entre o criador e o encadeamento criado; e
portanto, muitos tipos de condições de corrida no aplicativo não seriam relatados. Para
evitar tal ordem falsa, esta opção de linha de comando é definida como sim por padrão em
Solaris. Todas as atividades (carregamentos, armazenamentos, solicitações de clientes) são, portanto, ignoradas durante:

· Chamada pthread_create () no thread do criador

· Fase de criação de thread (configuração de pilha e TLS) no thread criado

--trace-addr = [predefinição: Nenhum]
Rastreie todas as atividades de carregamento e armazenamento para o endereço especificado. Esta opção pode ser
especificado mais de uma vez.

--ptrace-addr = [predefinição: Nenhum]
Rastreie toda a atividade de carga e armazenamento para o endereço especificado e continue fazendo isso até
depois que a memória naquele endereço foi liberada e realocada.

--trace-alloc = [predefinição: não]
Rastreie todas as alocações e desalocações de memória. Pode produzir uma grande quantidade de saída.

--trace-barreira = [predefinição: não]
Rastreie todas as atividades de barreira.

--trace-cond = [predefinição: não]
Rastreie todas as atividades das variáveis ​​de condição.

--trace-fork-join = [predefinição: não]
Rastreie toda a criação de encadeamento e todos os eventos de encerramento de encadeamento.

--trace-hb = [predefinição: não]
Rastreie a execução de ANNOTATE_HAPPENS_BEFORE (), ANNOTATE_HAPPENS_AFTER () e
ANNOTATE_HAPPENS_DONE () solicitações do cliente.

--trace-mutex = [predefinição: não]
Rastreie todas as atividades mutex.

--trace-rwlock = [predefinição: não]
Rastreie todas as atividades de bloqueio de leitor-gravador.

--trace-semaphore = [predefinição: não]
Rastreie todas as atividades do semáforo.

MACIÇO OPÇÕES

--heap = [predefinição: sim]
Especifica se o perfil de heap deve ser feito.

--heap-admin = [predefinição: 8]
Se o perfil de heap estiver habilitado, fornece o número de bytes administrativos por bloco para
usar. Deve ser uma estimativa da média, pois pode variar. Por exemplo, o
alocador usado por glibc no Linux requer algo entre 4 a 15 bytes por bloco,
dependendo de vários fatores. Esse alocador também requer espaço de administrador para liberar
blocos, mas Massif não pode explicar isso.

--stacks = [predefinição: não]
Especifica se o perfil da pilha deve ser feito. Esta opção retarda o maciço
muito e, portanto, está desativado por padrão. Observe que o Massif assume que a pilha principal tem
tamanho zero na inicialização. Isso não é verdade, mas fazer o contrário com precisão é difícil.
Além disso, começar do zero indica melhor o tamanho da parte da pilha principal
sobre o qual um programa do usuário realmente tem controle.

--pages-as-heap = [predefinição: não]
Diz ao Massif para criar um perfil de memória no nível da página, em vez de no bloco malloc.
nível. Veja acima para detalhes.

--depth = [predefinição: 30]
Profundidade máxima das árvores de alocação registradas para instantâneos detalhados. Aumentando
fará o Massif funcionar um pouco mais devagar, usará mais memória e produzirá uma saída maior
arquivos.

--alloc-fn =
As funções especificadas com esta opção serão tratadas como se fossem uma pilha
função de alocação, como Malloc. Isso é útil para funções que são wrappers para
Malloc or novo, que pode preencher as árvores de alocação com informações desinteressantes.
Esta opção pode ser especificada várias vezes na linha de comando, para nomear vários
funções.

Observe que a função nomeada só será tratada desta forma se for a entrada superior em um
rastreamento de pilha, ou logo abaixo de outra função tratada desta forma. Por exemplo, se você tiver
uma função malloc1 que envolve Malloc e malloc2 que envolve malloc1, apenas especificando
--alloc-fn = malloc2 não terá efeito. Você precisa especificar --alloc-fn = malloc1 as
Nós vamos. Isso é um pouco inconveniente, mas o motivo é que a verificação de alocação
funções são lentas e economiza muito tempo se o Massif puder parar de olhar através do
empilhar entradas de rastreamento assim que encontrar uma que não corresponda, em vez de ter que
continue por todas as entradas.

Observe que os nomes C ++ são eliminados. Observe também que nomes C ++ sobrecarregados devem ser escritos
na íntegra. As aspas simples podem ser necessárias para evitar que o shell os divida.
Por exemplo:

--alloc-fn = 'operador novo (sem sinal, std :: nothrow_t const &)'

--ignore-fn =
Qualquer alocação de heap direta (ou seja, uma chamada para Malloc, novo, etc, ou uma chamada para uma função
nomeado por um --alloc-fn opção) que ocorre em uma função especificada por esta opção irá
ser ignorado. Isso é útil principalmente para fins de teste. Esta opção pode ser especificada
várias vezes na linha de comando, para nomear várias funções.

Qualquer realocar de um bloco ignorado também será ignorado, mesmo se o realocar ligar faz
não ocorre em uma função ignorada. Isso evita a possibilidade de tamanhos de heap negativos
se os blocos ignorados forem reduzidos com realocar.

As regras para escrever nomes de função C ++ são as mesmas para --alloc-fn acima.

--threshold = [predefinição: 1.0]
O limite de significância para alocações de heap, como uma porcentagem do tamanho total da memória.
As entradas da árvore de alocação que representam menos do que isso serão agregadas. Observe que
isso deve ser especificado em conjunto com a opção de ms_print de mesmo nome.

--peak-imprecuracy = [predefinição: 1.0]
Massif não registra necessariamente o pico de alocação de memória global real; por
padrão, ele registra um pico apenas quando o tamanho da alocação de memória global excede o
pico anterior em pelo menos 1.0%. Isso ocorre porque pode haver muitas alocações locais
picos ao longo do caminho, e fazer um instantâneo detalhado para cada um seria caro
e um desperdício, pois todos, exceto um deles, serão posteriormente descartados. Esta imprecisão pode ser
alterado (mesmo para 0.0%) por meio desta opção, mas o Massif será executado drasticamente mais lento que o
o número se aproxima de zero.

--time-unit = [predefinição: i]
A unidade de tempo usada para o perfil. Existem três possibilidades: instruções
executado (i), o que é bom para a maioria dos casos; tempo real (relógio de parede) (ms, ou seja
milissegundos), que às vezes é útil; e bytes alocados / desalocados no heap
e / ou pilha (B), que é útil para programas de execução muito curta e para teste
finalidades, porque é o mais reproduzível em diferentes máquinas.

--detailed-freq = [predefinição: 10]
Frequência de instantâneos detalhados. Com --detailed-freq = 1, cada instantâneo é detalhado.

--max-snapshots = [predefinição: 100]
O número máximo de instantâneos gravados. Se definido como N, para todos os programas, exceto muito
de curta duração, o número final de instantâneos ficará entre N / 2 e N.

--massif-out-file = [predefinição: massif.out.% p]
Grave os dados do perfil no arquivo em vez de no arquivo de saída padrão,
massif.out. . o %p e %q especificadores de formato podem ser usados ​​para incorporar o ID do processo
e / ou o conteúdo de uma variável de ambiente no nome, como é o caso do
opção central --arquivo de log.

VERIFICAÇÃO SG OPÇÕES

Não há opções de linha de comando específicas do SGCheck no momento.

BBV OPÇÕES

--bb-out-file = [predefinição: bb.out.% p]
Esta opção seleciona o nome do arquivo vetorial de bloco básico. o %p e %q formato
especificadores podem ser usados ​​para incorporar o ID do processo e / ou o conteúdo de um ambiente
variável no nome, como é o caso da opção principal --arquivo de log.

--pc-out-file = [predefinição: pc.out.% p]
Esta opção seleciona o nome do arquivo do PC. Este arquivo contém endereços de contador de programa
e informações do nome da função para os vários blocos básicos. Isso pode ser usado em conjunto
com o arquivo de vetor de bloco básico para avançar por meio de nomes de funções em vez de apenas
conta de instrução. o %p e %q especificadores de formato podem ser usados ​​para incorporar o processo
ID e / ou o conteúdo de uma variável de ambiente no nome, como é o caso do
opção central --arquivo de log.

--interval-size = [predefinição: 100000000]
Esta opção seleciona o tamanho do intervalo a ser usado. O padrão é 100 milhões
instruções, que é um valor comumente usado. Outros tamanhos podem ser usados; menor
os intervalos podem ajudar os programas com fases mais refinadas. No entanto, tamanho de intervalo menor
pode levar a problemas de precisão devido a efeitos de aquecimento (Ao avançar os vários
os recursos arquitetônicos serão não inicializados e levará um certo número de
instruções antes de "aquecerem" para o estado em que uma simulação completa estaria sem
o avanço rápido. Os tamanhos de intervalo grandes tendem a atenuar isso.)

--instr-contagem-somente [predefinição: não]
Esta opção diz à ferramenta para exibir apenas os totais de contagem de instruções e não
gerar o arquivo vetorial de bloco básico real. Isso é útil para depuração e para
coleta de informações de contagem de instruções sem gerar o grande vetor de bloco básico
arquivos.

LACAIO OPÇÕES

--basic-counts = [predefinição: sim]
Quando habilitado, o Lackey imprime as seguintes estatísticas e informações sobre o
execução do programa cliente:

1. O número de chamadas para a função especificada pelo --fnname opção (o padrão
é principal). Se o programa teve seus símbolos removidos, a contagem será sempre
zero.

2. O número de ramos condicionais encontrados e o número e proporção de
aqueles tirados.

3. O número de superblocos inseridos e concluídos pelo programa. Observe que devido a
otimizações feitas pelo JIT, este não é um valor preciso.

4. O número de instruções de convidado (x86, amd64, ppc, etc.) e declarações de IR
executado. IR é a representação intermediária do tipo RISC do Valgrind, por meio da qual todos
a instrumentação é feita.

5. Razões entre algumas dessas contagens.

6. O código de saída do programa cliente.

--detailed-counts = [predefinição: não]
Quando habilitado, o Lackey imprime uma tabela contendo contagens de cargas, armazenamentos e ALU
operações, diferenciadas por seus tipos de IR. Os tipos de IR são identificados por seus IR
nome ("I1", "I8", ... "I128", "F32", "F64" e "V128").

--trace-mem = [predefinição: não]
Quando ativado, o Lackey imprime o tamanho e o endereço de quase todos os acessos à memória feitos por
o programa. Veja os comentários no topo do arquivo lacaio / lk_main.c para detalhes
sobre o formato de saída, como funciona e imprecisões no rastreamento de endereço. Observação
que esta opção produz quantidades imensas de saída.

--trace-superblocks = [predefinição: não]
Quando ativado, o Lackey imprime o endereço de cada superbloco (uma única entrada,
saída múltipla, pedaço linear de código) executado pelo programa. Isto é principalmente de
interesse para desenvolvedores Valgrind. Veja os comentários no topo do arquivo
lacaio / lk_main.c para obter detalhes sobre o formato de saída. Observe que esta opção produz
grandes quantidades de produção.

--fnname = [predefinição: a Principal]
Altera a função para a qual as chamadas são contadas quando --basic-counts = sim é especificado.

Use valgrind.bin online usando serviços onworks.net