valgrind.bin: online nel cloud

PROGRAMMA:

NOME

valgrind - una suite di strumenti per il debug e la profilazione dei programmi

SINOSSI

valgrind [valgrind-opzioni] [il-tuo-programma] [le-vostre-opzioni-programma]

DESCRIZIONE

valgrind è un programma flessibile per il debug e la profilazione degli eseguibili Linux. Consiste
di un core, che fornisce una CPU sintetica nel software, e una serie di debug e
strumenti di profilazione. L'architettura è modulare, in modo da poter creare facilmente nuovi strumenti e
senza disturbare la struttura esistente.

Alcune delle opzioni descritte di seguito funzionano con tutti gli strumenti Valgrind e alcune funzionano solo con
pochi o uno. La sezione OPZIONI MEMCHECK e quelle seguenti descrivono lo strumento specifico
opzioni.

Questa pagina del manuale copre solo l'utilizzo e le opzioni di base. Per informazioni più complete,
si prega di consultare la documentazione HTML sul proprio sistema:
$INSTALL/share/doc/valgrind/html/index.html, oppure online:
http://www.valgrind.org/docs/manual/index.html.

TOOL SELEZIONE VERSIONI

L'unica opzione più importante.

--strumento= [predefinito: controllo mem]
Esegui lo strumento Valgrind chiamato nomeutensile, ad esempio memcheck, cachegrind, callgrind, helgrind,
drd, massif, lackey, none, exp-sgcheck, exp-bbv, exp-dhat, ecc.

BASIC VERSIONI

Queste opzioni funzionano con tutti gli strumenti.

-h --Aiuto
Mostra la guida per tutte le opzioni, sia per il core che per lo strumento selezionato. Se l'opzione
si ripete equivale a dare --help-debug.

--help-debug
Uguale a --Aiuto, ma elenca anche le opzioni di debug che di solito sono utili solo per
Gli sviluppatori di Valgrind.

--versione
Mostra il numero di versione del core Valgrind. Gli strumenti possono avere la propria versione
numeri. Esiste uno schema in atto per garantire che gli strumenti vengano eseguiti solo quando il core
versione è quella con cui sono noti per lavorare. Questo è stato fatto per ridurre al minimo le possibilità di
strani problemi derivanti da incompatibilità tra le versioni tool-vs-core.

-q, --silenzioso
Esegui in silenzio e stampa solo i messaggi di errore. Utile se stai eseguendo una regressione
test o avere qualche altro macchinario di prova automatizzato.

-v, --verboso
Sii più prolisso. Fornisce informazioni aggiuntive su vari aspetti del programma, ad esempio:
gli oggetti condivisi caricati, le soppressioni utilizzate, l'andamento della strumentazione
e motori di esecuzione e avvisi su comportamenti insoliti. Ripetendo l'opzione
aumenta il livello di verbosità.

--trace-bambini= [predefinito: No]
Quando abilitato, Valgrind traccerà in sottoprocessi avviati tramite il exec sistema
chiamata. Ciò è necessario per i programmi multiprocesso.

Si noti che Valgrind rintraccia nel figlio di a forcella (sarebbe difficile non farlo,
da forcella fa una copia identica di un processo), quindi questa opzione è probabilmente male
di nome. Tuttavia, la maggior parte dei bambini di forcella chiama subito chiama exec comunque.

--trace-children-skip=patt1,patt2,...
Questa opzione ha effetto solo quando --trace-bambini=sì è specificato. permette
alcuni bambini da saltare. L'opzione richiede un elenco di modelli separati da virgole per
i nomi degli eseguibili figlio a cui Valgrind non dovrebbe risalire. I modelli possono
includere i metacaratteri ? e *, che hanno il significato usuale.

Questo può essere utile per potare rami non interessanti da un albero di processi in corso
correre su Valgrind. Ma dovresti stare attento quando lo usi. Quando Valgrind salta il tracciamento
in un eseguibile, non solo salta la traccia di quell'eseguibile, ma salta anche
tracciare uno qualsiasi dei processi figlio di quell'eseguibile. In altre parole, la bandiera no
fa sì che la traccia si fermi agli eseguibili specificati: salta la traccia di
interi sottoalberi del processo radicati in uno qualsiasi degli eseguibili specificati.

--trace-children-skip-by-arg=patt1, patt2,...
Questo è lo stesso di --trace-bambini-skip, con una differenza: la decisione di
se rintracciare in un processo figlio viene effettuato esaminando gli argomenti al figlio
processo, piuttosto che il nome del suo eseguibile.

--child-silent-after-fork= [predefinito: No]
Quando abilitato, Valgrind non mostrerà alcun output di debug o di registrazione per il bambino
processo risultante da a forcella chiamata. Questo può rendere l'output meno confuso (anche se
più fuorviante) quando si tratta di processi che creano bambini. È particolarmente
utile in combinazione con --trace-bambini=. Anche l'uso di questa opzione è fortemente
consigliato se si richiede l'output XML (--xml=sì), poiché altrimenti l'XML da
bambino e genitore possono confondersi, il che di solito lo rende inutile.

--vgdb= [predefinito: sì]
Valgrind fornirà la funzionalità "gdbserver" quando --vgdb=sì or --vgdb=pieno is
specificato. Ciò consente a un debugger GNU GDB esterno di controllare ed eseguire il debug del programma
quando funziona su Valgrind. --vgdb=pieno comporta notevoli spese generali per le prestazioni, ma
fornisce breakpoint e watchpoint più precisi. Vedere Debug del programma utilizzando
gdbserver e GDB di Valgrind per una descrizione dettagliata.

Se il gdbserver incorporato è abilitato ma non è attualmente in uso gdb, il vgdb
l'utilità della riga di comando può inviare "comandi di monitoraggio" a Valgrind da una shell. Il
Valgrind core fornisce una serie di comandi del monitor Valgrind. Uno strumento può facoltativamente
fornire comandi di monitoraggio specifici dello strumento, che sono documentati nello strumento specifico
capitolo.

--vgdb-error= [predefinito: 999999999]
Usa questa opzione quando Valgrind gdbserver è abilitato con --vgdb=sì or --vgdb=pieno.
Gli strumenti che segnalano errori attenderanno la segnalazione di errori "numero" prima del blocco
il programma e in attesa che tu ti colleghi con GDB. Ne segue che un valore pari a zero
avvierà gdbserver prima che il programma venga eseguito. Questo è
tipicamente utilizzato per inserire punti di interruzione GDB prima dell'esecuzione e funziona anche con gli strumenti
che non riportano errori, come Massif.

--vgdb-stop-at= [predefinito: nessuno]
Usa questa opzione quando Valgrind gdbserver è abilitato con --vgdb=sì or --vgdb=pieno.
Il Valgrind gdbserver verrà invocato per ogni errore successivo --vgdb-errore sono stati
segnalato. Puoi inoltre chiedere al Valgrind gdbserver di essere invocato per altri
eventi, specificati in uno dei seguenti modi:

· un elenco separato da virgole di uno o più di startup exit valgrindabexit.

I valori startup exit valgrindabexit rispettivamente indicare di invocare gdbserver
prima che il tuo programma venga eseguito, dopo l'ultima istruzione del tuo programma, on
Uscita anomala da Valgrind (es. errore interno, memoria esaurita, ...).

Nota: startup e --vgdb-errore=0 entrambi causeranno l'invocazione di Valgrind gdbserver
prima che il programma venga eseguito. Il --vgdb-errore=0 causerà inoltre il tuo
programma di fermarsi su tutti gli errori successivi.

· contro tutti i per specificare l'insieme completo. È equivalente a
--vgdb-stop-at=avvio,uscita,valgrindabexit.

· nessuna per l'insieme vuoto

--track-fds= [predefinito: No]
Quando abilitato, Valgrind stamperà un elenco di descrittori di file aperti all'uscita o all'accensione
richiesta, tramite il comando gdbserver monitor v.info open_fds. Insieme a ogni file
descrittore viene stampato un backtrace dello stack di dove è stato aperto il file e tutti i dettagli
relative al descrittore di file come il nome del file o i dettagli del socket.

--time-stamp= [predefinito: No]
Quando abilitato, ogni messaggio è preceduto dall'indicazione del wallclock trascorso
tempo dall'avvio, espresso in giorni, ore, minuti, secondi e millisecondi.

--log-fd= [predefinito: 2, stder]
Specifica che Valgrind deve inviare tutti i suoi messaggi al file specificato
descrittore. Il valore predefinito, 2, è il canale di errore standard (stderr). Nota che questo potrebbe
interferire con l'uso di stderr da parte del client, poiché l'output di Valgrind sarà
interlacciato con qualsiasi output che il client invia a stderr.

--file-log=
Specifica che Valgrind deve inviare tutti i suoi messaggi al file specificato. Se la
il nome del file è vuoto, provoca un'interruzione. Ci sono tre identificatori di formato speciali che
può essere utilizzato nel nome del file.

%p viene sostituito con l'ID del processo corrente. Questo è molto utile per il programma che
invocare più processi. ATTENZIONE: Se si utilizza --trace-bambini=sì e il tuo programma
invoca più processi OPPURE il tuo programma esegue il fork senza chiamare exec in seguito e
non usi questo specificatore (o il %q specificatore di seguito), l'output Valgrind da all
quei processi andranno in un file, possibilmente confuso e forse incompleto.

%q{FOO} viene sostituito con il contenuto della variabile d'ambiente FOO. Se il {FOO}
parte è malformata, provoca un'interruzione. Questo specificatore è raramente necessario, ma molto
utile in determinate circostanze (es. durante l'esecuzione di programmi MPI). L'idea è che tu
specificare una variabile che sarà impostata in modo diverso per ogni processo nel lavoro, per
esempio BPROC_RANK o qualunque cosa sia applicabile nella tua configurazione MPI. Se il nome
la variabile di ambiente non è impostata, provoca un'interruzione. Nota che in alcune shell, il {
e } potrebbe essere necessario sfuggire ai caratteri con una barra rovesciata.

%% viene sostituito con %.

Se uno % è seguito da qualsiasi altro carattere, provoca un'interruzione.

Se il nome del file specifica un nome di file relativo, viene inserito nell'iniziale del programma
directory di lavoro: questa è la directory corrente quando il programma è stato avviato
esecuzione dopo il fork o dopo l'exec. Se specifica un nome di file assoluto (es.
inizia con '/'), quindi viene inserito lì.

--log-socket=
Specifica che Valgrind deve inviare tutti i suoi messaggi alla porta specificata al
indirizzo IP specificato. La porta può essere omessa, nel qual caso viene utilizzata la porta 1500. Se un
la connessione non può essere effettuata alla presa specificata, Valgrind ritorna alla scrittura
l'output nell'errore standard (stderr). Questa opzione è destinata all'uso in
in combinazione con il programma valgrind-ascoltatore. Per ulteriori dettagli, vedere il
commento nel manuale.

CORRELATI AGLI ERRORI VERSIONI

Queste opzioni sono utilizzate da tutti gli strumenti che possono segnalare errori, ad esempio Memcheck, ma non
Cachegrind.

--xml= [predefinito: No]
Quando abilitato, le parti importanti dell'output (ad esempio i messaggi di errore dello strumento) saranno in
Formato XML anziché testo normale. Inoltre, l'output XML verrà inviato a a
canale di output diverso dall'output di testo normale. Pertanto, devi anche usarne uno
of --xml-fd, --file-xml or --xml-socket per specificare dove deve essere inviato l'XML.

I messaggi meno importanti verranno comunque stampati in testo normale, ma poiché l'XML
output e output di testo normale vengono inviati a diversi canali di output (la destinazione di
l'output del testo in chiaro è ancora controllato da --log-fd, --file-log e --log-socket)
questo non dovrebbe creare problemi.

Questa opzione ha lo scopo di semplificare la vita agli strumenti che consumano l'output di Valgrind come
input, come i front-end della GUI. Attualmente questa opzione funziona con Memcheck, Helgrind,
DRD e SGcheck. Il formato di output è specificato nel file
docs/internals/xml-output-protocol4.txt nell'albero dei sorgenti per Valgrind 3.5.0 o
successivamente.

Le opzioni consigliate per il passaggio di una GUI, quando si richiede l'output XML, sono: --xml=sì
per abilitare l'output XML, --file-xml per inviare l'output XML a un (presumibilmente selezionato dalla GUI)
file, --file-log per inviare l'output di testo normale a un secondo file selezionato dalla GUI,
--child-silent-after-fork=sìe -q per limitare l'output di testo normale a critico
messaggi di errore creati da Valgrind stesso. Ad esempio, la mancata lettura di un determinato
Il file di soppressioni conta come un messaggio di errore critico. In questo modo, per un successo
eseguire il file di output di testo sarà vuoto. Ma se non è vuoto, allora conterrà
informazioni importanti di cui l'utente della GUI dovrebbe essere a conoscenza.

--xml-fd= [predefinito: -1, Disabilitato]
Specifica che Valgrind deve inviare il proprio output XML al descrittore di file specificato.
Deve essere utilizzato in combinazione con --xml=sì.

--xml-file=
Specifica che Valgrind deve inviare il proprio output XML al file specificato. Deve essere
usato insieme a --xml=sì. Qualsiasi %p or %q sequenze che appaiono nel nome del file
sono espansi esattamente nello stesso modo in cui lo sono per --file-log. Vedi la descrizione
of --file-log per i dettagli.

--xml-socket=
Specifica che Valgrind deve inviare il suo output XML alla porta specificata all'indirizzo specificato
Indirizzo IP. Deve essere utilizzato in combinazione con --xml=sì. La forma dell'argomento è
lo stesso di quello usato da --log-socket. Vedi la descrizione di --log-socket per ulteriori
dettagli.

--xml-user-comment=
Incorpora una stringa di commento utente aggiuntiva all'inizio dell'output XML. Funziona solo quando
--xml=sì è specificato; ignorato altrimenti.

--demangle= [predefinito: sì]
Abilita/disabilita la decodifica automatica (decodifica) dei nomi C++. Abilitato per impostazione predefinita. quando
abilitato, Valgrind tenterà di tradurre i nomi C++ codificati in qualcosa
avvicinandosi all'originale. Il demangler gestisce i simboli alterati dalle versioni di g++ 2.X,
3.X e 4.X.

Un fatto importante sul smantellamento è che i nomi delle funzioni menzionati nelle soppressioni
i file dovrebbero essere nella loro forma alterata. Valgrind non smantella i nomi delle funzioni quando
alla ricerca di soppressioni applicabili, perché fare diversamente significherebbe sopprimere
il contenuto del file dipende dallo stato del macchinario di smantellamento di Valgrind e anche lento
corrispondenza di soppressione verso il basso.

--num-chiamanti= [predefinito: 12]
Specifica il numero massimo di voci mostrate nelle tracce dello stack che identificano il programma
posizioni. Nota che gli errori sono comuni utilizzando solo le prime quattro posizioni delle funzioni
(il posto nella funzione corrente e quello dei suoi tre chiamanti immediati). Così questo
non influisce sul numero totale di errori segnalati.

Il valore massimo per questo è 500. Notare che impostazioni più alte faranno funzionare Valgrind a
un po' più lentamente e richiede un po' più di memoria, ma può essere utile quando si lavora con
programmi con catene di chiamate profondamente nidificate.

--unw-stack-scan-thresh= [predefinito: 0] , --unw-stack-scan-frames= [predefinito:
5]
Il supporto per la scansione dello stack è disponibile solo sui target ARM.

Questi flag abilitano e controllano lo srotolamento dello stack mediante la scansione dello stack. Quando la normalità
meccanismi di srotolamento dello stack: utilizzo di record CFI nani e inseguimento di frame-pointer
-- fallisce, la scansione dello stack potrebbe essere in grado di recuperare una traccia dello stack.

Nota che la scansione dello stack è un meccanismo euristico impreciso che può dare molto
risultati fuorvianti o del tutto assenti. Dovrebbe essere usato solo in caso di emergenza, quando normale
lo srotolamento non riesce ed è comunque importante disporre di tracce dello stack.

La scansione della pila è una tecnica semplice: lo svolgitore legge le parole dalla pila e
cerca di indovinare quali di essi potrebbero essere indirizzi di ritorno, controllando per vedere se
punto subito dopo le istruzioni di chiamata ARM o Thumb. In caso affermativo, la parola viene aggiunta al
indietro.

Il pericolo principale si verifica quando una chiamata di funzione ritorna, lasciando il suo indirizzo di ritorno
esposta e viene chiamata una nuova funzione, ma la nuova funzione non sovrascrive la vecchia
indirizzo. Il risultato è che il backtrace può contenere voci per le funzioni
che sono già tornati, e quindi crea molta confusione.

Una seconda limitazione di questa implementazione è che eseguirà la scansione solo della pagina (4KB,
normalmente) contenente il puntatore dello stack iniziale. Se gli stack frame sono grandi, questo
può comportare che solo alcuni (o addirittura nessuno) siano presenti nella traccia. Inoltre, se tu
sono sfortunati e hanno un puntatore allo stack iniziale vicino alla fine della pagina che lo contiene, il
la scansione potrebbe perdere tutti i fotogrammi interessanti.

Per impostazione predefinita, la scansione dello stack è disabilitata. Il caso d'uso normale è chiederlo quando a
la traccia dello stack sarebbe altrimenti molto breve. Quindi, per abilitarlo, usa
--unw-stack-scan-thresh=numero. Ciò richiede a Valgrind di provare a utilizzare la scansione dello stack per
"estendere" le tracce dello stack che contengono meno di un numero di frame.

Se la scansione dello stack ha luogo, genererà al massimo solo il numero di frame
specificato da --unw-stack-scan-frames. In genere, la scansione dello stack ne genera così tante
voci spazzatura che questo valore è impostato su un valore basso (5) per impostazione predefinita. In nessun caso
viene creata una traccia dello stack maggiore del valore specificato da --num-callers.

--limite-errore= [predefinito: sì]
Quando abilitato, Valgrind smette di segnalare errori dopo 10,000,000 in totale, o 1,000
diversi, sono stati visti. Questo serve per fermare il meccanismo di tracciamento degli errori da
diventando un enorme sovraccarico di prestazioni in programmi con molti errori.

--error-exitcode= [predefinito: 0]
Specifica un codice di uscita alternativo da restituire se Valgrind ha segnalato errori nel
correre. Quando è impostato sul valore predefinito (zero), il valore restituito da Valgrind sarà sempre
essere il valore di ritorno del processo simulato. Quando è impostato su un valore diverso da zero, questo
viene invece restituito il valore se Valgrind rileva errori. Questo è utile per l'uso
Valgrind come parte di una suite di test automatizzata, poiché semplifica l'individuazione dei test
casi per i quali Valgrind ha segnalato errori, semplicemente ispezionando i codici di ritorno.

--error-markers= , [predefinito: nessuno]
Quando gli errori vengono emessi come testo normale (ovvero XML non utilizzato), --indicatori di errore istruisce a
emette una riga contenente il iniziare (fine) stringa prima (dopo) ogni errore.

Tali linee di marker facilitano la ricerca di errori e/o l'estrazione di errori in un
file di output che contengono errori di valgrind mescolati con l'output del programma.

Notare che i marker vuoti sono accettati. Quindi, usare solo un indicatore di inizio (o fine) è
possibile.

--sigill-diagnostics= [predefinito: sì]
Abilita/disabilita la stampa della diagnostica delle istruzioni illegali. Abilitato per impostazione predefinita, ma
il valore predefinito è disabilitato quando --silenzioso viene data. L'impostazione predefinita può sempre essere esplicitamente
sovrascritto dando questa opzione.

Quando abilitato, verrà stampato un messaggio di avviso, insieme ad alcuni dati diagnostici, ogni volta che
viene rilevata un'istruzione che Valgrind non è in grado di decodificare o tradurre, prima del
programma riceve un segnale SIGILL. Spesso un'istruzione illegale indica un bug nel
programma o supporto mancante per l'istruzione particolare in Valgrind. Ma alcuni
i programmi cercano deliberatamente di eseguire un'istruzione che potrebbe mancare e intrappolare
il segnale SIGILL per rilevare le caratteristiche del processore. L'uso di questo flag consente di
evitare l'output diagnostico che altrimenti si otterrebbe in questi casi.

--show-below-main= [predefinito: No]
Per impostazione predefinita, le tracce dello stack per gli errori non mostrano alcuna funzione che appare sotto principale
perché la maggior parte delle volte è roba da libreria C non interessante e/o gobbledygook.
In alternativa, se principale non è presente nella traccia dello stack, le tracce dello stack non verranno mostrate
qualsiasi funzione di seguito principalefunzioni simili a quelle di glibc __libc_start_main.
Inoltre, se principale-funzioni simili sono presenti nella traccia, sono normalizzate come
(sotto principale), al fine di rendere l'output più deterministico.

Se questa opzione è abilitata, verranno mostrate tutte le voci di traccia dello stack e principale-Like
le funzioni non saranno normalizzate.

--fullpath-after= [predefinito: non mostrare attraverso le sue creazioni source percorsi]
Per impostazione predefinita Valgrind mostra solo i nomi dei file nelle tracce dello stack, ma non i percorsi completi per
file sorgenti. Quando si utilizza Valgrind in progetti di grandi dimensioni in cui risiedono le fonti
più directory diverse, questo può essere scomodo. --fullpath-dopo fornisce un
soluzione flessibile a questo problema. Quando questa opzione è presente, il percorso di ciascuno
viene mostrato il file sorgente, con la seguente importantissima avvertenza: if stringa si trova in
il sentiero, poi il sentiero fino a compreso stringa viene omesso, altrimenti viene mostrato il percorso
non modificato. Notare che stringa non è necessario che sia un prefisso del percorso.

Ad esempio, considera un file chiamato /home/janedoe/blah/src/foo/bar/xyzzy.c. Specificando
--fullpath-after=/home/janedoe/blah/src/ farà sì che Valgrind mostri il nome come
foo/bar/xyzzy.c.

Poiché non è necessario che la stringa sia un prefisso, --fullpath-after=src/ produrrà
la stessa uscita. Questo è utile quando il percorso contiene dati generati dalla macchina arbitrari
caratteri. Ad esempio, il percorso /my/build/dir/C32A1B47/blah/src/foo/xyzzy può essere
potato a foo/xyzzy usando --fullpath-after=/bla/src/.

Se vuoi semplicemente vedere il percorso completo, specifica semplicemente una stringa vuota:
--fullpath-dopo=. Questo non è un caso speciale, solo una logica conseguenza del
regole di cui sopra.

Finalmente puoi usare --fullpath-dopo più volte. Qualsiasi aspetto di esso provoca
Valgrind per passare alla produzione di percorsi completi e applicare la regola di filtraggio di cui sopra. Ogni
percorso prodotto viene confrontato con tutti i --fullpath-dopo-stringhe specificate, in
ordine specificato. La prima stringa che corrisponde fa sì che il percorso venga troncato come
descritto sopra. Se nessuno corrisponde, viene mostrato il percorso completo. Questo facilita il taglio
prefissi quando le fonti sono tratte da una serie di directory non correlate.

--extra-debuginfo-path= [predefinito: indefinito e inutilizzato]
Per impostazione predefinita Valgrind cerca in diversi percorsi noti gli oggetti di debug, come
/usr/lib/debug/.

Tuttavia, potrebbero esserci scenari in cui potresti voler mettere oggetti di debug in un
posizione arbitraria, come l'archiviazione esterna durante l'esecuzione di Valgrind su un dispositivo mobile
con spazio di archiviazione locale limitato. Un altro esempio potrebbe essere una situazione in cui non hai
permesso di installare pacchetti di oggetti di debug sul sistema in cui stai eseguendo
Valgrind.

In questi scenari, potresti fornire un percorso assoluto come luogo extra e finale per
Valgrind per cercare oggetti di debug specificando
--extra-debuginfo-path=/percorso/a/debug/oggetti. Il percorso indicato sarà anteposto al
nome del percorso assoluto dell'oggetto cercato. Ad esempio, se Valgrind sta cercando
le informazioni di debug per /w/x/y/zz.so e --extra-debuginfo-path=/a/b/c è specificato, sarà
cerca un oggetto di debug in /a/b/c/w/x/y/zz.so.

Questo flag deve essere specificato solo una volta. Se viene specificato più volte, solo il
l'ultima istanza è onorata.

--debuginfo-server=ipaddr:porta [predefinito: indefinito e inutilizzato]
Questa è una nuova funzionalità sperimentale introdotta nella versione 3.9.0.

In alcuni scenari può essere conveniente leggere le informazioni di debug dagli oggetti archiviati su a
macchina diversa. Con questo flag, Valgrind interrogherà un server di debuginfo in esecuzione su
ipaddr e in ascolto sulla porta della porta, se non riesce a trovare l'oggetto debuginfo nel locale
file system.

Il server debuginfo deve accettare connessioni TCP sulla porta. Il server delle informazioni di debug è
contenuto nel file sorgente auxprogs/valgrind-di-server.c. Servirà solo da
la directory in cui viene avviato. la porta predefinita è 1500 sia nel client che nel server se
non specificato.

Se Valgrind cerca le informazioni di debug per /w/x/y/zz.so utilizzando il server di informazioni di debug,
rimuoverà i componenti del percorso e richiederà semplicemente zz.so sul server. che in
turn cercherà solo nella sua directory di lavoro corrente un oggetto debuginfo corrispondente.

I dati di debuginfo vengono trasmessi in piccoli frammenti (8 KB) come richiesto da Valgrind.
Ogni blocco viene compresso utilizzando LZO per ridurre il tempo di trasmissione. L'attuazione ha
è stato ottimizzato per ottenere le migliori prestazioni su un collegamento di rete 802.11g (WiFi) a stadio singolo.

Nota che controlla la corrispondenza tra oggetti primari e oggetti di debug, usando GNU debuglink CRC
schema, vengono eseguiti anche quando si utilizza il server debuginfo. Per disabilitare tale controllo,
devi anche specificare --allow-mismatched-debuginfo=yes.

Per impostazione predefinita, il sistema di compilazione Valgrind creerà valgrind-di-server per il target
piattaforma, che quasi certamente non è quello che vuoi. Finora non siamo stati in grado di
scopri come ottenere automake/autoconf per compilarlo per la piattaforma di compilazione. Se vuoi
per usarlo, dovrai ricompilarlo a mano usando il comando mostrato in cima a
auxprogs/valgrind-di-server.c.

--allow-mismatched-debuginfo=no|sì [No]
Quando si legge debuginfo da oggetti debuginfo separati, Valgrind controllerà per impostazione predefinita
che gli oggetti main e debuginfo corrispondano, utilizzando il meccanismo GNU debuglink. Questo
garantisce che non legga debuginfo da oggetti debuginfo non aggiornati e
assicura inoltre che Valgrind non possa andare in crash a causa di disallineamenti.

Questo controllo può essere sovrascritto usando --allow-mismatched-debuginfo=yes. Può essere
utile quando gli oggetti debuginfo e main non sono stati suddivisi in modo corretto. Essere
attenzione quando si utilizza questo, però: disabilita tutti i controlli di coerenza e Valgrind
è stato osservato un arresto anomalo quando gli oggetti main e debuginfo non corrispondono.

--soppressioni= [predefinito: $PREFIX/lib/valgrind/default.supp]
Specifica un file aggiuntivo da cui leggere le descrizioni degli errori da eliminare. Potresti
utilizzare fino a 100 file di soppressione extra.

--gen-soppressions= [predefinito: No]
Quando impostato su sì, Valgrind si fermerà dopo ogni errore mostrato e stamperà la riga:

---- Soppressione della stampa ? --- [Ritorno/N/n/S/a/C/c] ----

Pressatura Macerare, o N Macerare or n Macerare, fa sì che Valgrind continui l'esecuzione senza stampare a
soppressione per questo errore.

Pressatura Y Macerare or y Macerare fa in modo che Valgrind scriva una soppressione per questo errore. Puoi
quindi taglialo e incollalo in un file di soppressione se non vuoi sentirne parlare
errore in futuro.

Quando impostato su contro tutti i, Valgrind stamperà una soppressione per ogni errore segnalato, senza
interrogare l'utente.

Questa opzione è particolarmente utile con i programmi C++, in quanto stampa il
soppressioni con nomi alterati, come richiesto.

Notare che le soppressioni stampate sono le più specifiche possibili. Potresti voler comune
simili, aggiungendo caratteri jolly ai nomi delle funzioni e utilizzando frame-level
caratteri jolly. Le strutture per i caratteri jolly sono potenti ma flessibili e con un po' di
modifica attenta, potresti essere in grado di sopprimere un'intera famiglia di errori correlati con
solo qualche soppressione.

A volte due errori diversi vengono soppressi dalla stessa soppressione, nel qual caso
Valgrind emetterà la soppressione più di una volta, ma devi averne solo una
copia nel file di soppressione (ma averne più di uno non causerà problemi). Anche,
il nome della soppressione è dato come ; il nome no
importa davvero, è usato solo con il -v opzione che stampa tutta la soppressione utilizzata
Records.

--input-fd= [predefinito: 0, standard]
Quando si usa --gen-suppressions=sì, Valgrind si fermerà per leggere l'input della tastiera
da te quando si verifica ogni errore. Di default legge dallo standard input (stdin),
che è problematico per i programmi che chiudono stdin. Questa opzione consente di specificare
un descrittore di file alternativo da cui leggere l'input.

--dsymutil=no|sì [sì]
Questa opzione è rilevante solo quando si esegue Valgrind su Mac OS X.

Mac OS X utilizza uno schema di collegamento delle informazioni di debug differite (debuginfo). Quando oggetto
i file contenenti debuginfo sono collegati in un .dylib o un eseguibile, il debuginfo è
non copiato nel file finale. Invece, le informazioni di debug devono essere collegate manualmente da
eseguire dsymutil, un'utilità fornita dal sistema, sull'eseguibile o su .dylib. Il
debuginfo combinato risultante viene inserito in una directory accanto all'eseguibile o
.dylib, ma con estensione .dSYM.

Con --dsymutil=no, Valgrind rileverà i casi in cui la directory .dSYM è o
mancante, o è presente ma non sembra corrispondere all'eseguibile associato o
.dylib, molto probabilmente perché non è aggiornato. In questi casi, Valgrind stamperà a
messaggio di avviso ma non intraprendere ulteriori azioni.

Con --dsymutil=sì, Valgrind, in tali casi, eseguirà automaticamente dsymutil as
necessario per aggiornare le informazioni di debug. Per tutti gli scopi pratici, se sempre
uso --dsymutil=sì, quindi non è mai necessario eseguire dsymutil manualmente o come parte
del sistema di compilazione delle applicazioni, poiché Valgrind lo eseguirà secondo necessità.

Valgrind non tenterà di eseguire dsymutil su alcun eseguibile o libreria in / usr /,
/ bidone /, / sbin /, / optare /, /sw/, /Sistema/, /Libreria/ o /Applicazioni/ poiché dsymutil lo farà
falliscono sempre in tali situazioni. Fallisce sia perché il debuginfo per tale
i componenti di sistema preinstallati non sono disponibili da nessuna parte e anche perché sarebbe
richiedono privilegi di scrittura in quelle directory.

Fai attenzione quando lo usi --dsymutil=sì, poiché causerà .dSYM . preesistente
directory da eliminare e ricreare silenziosamente. Nota anche che dsymutil è abbastanza
lento, a volte eccessivamente.

--max-stackframe= [predefinito: 2000000]
La dimensione massima di uno stack frame. Se il puntatore dello stack si sposta di più di questo importo
quindi Valgrind presumerà che il programma stia passando a uno stack diverso.

Potrebbe essere necessario utilizzare questa opzione se il programma dispone di grandi array allocati in stack.
Valgrind tiene traccia del puntatore dello stack del tuo programma. Se cambia di più del
soglia, Valgrind presume che il tuo programma stia passando a uno stack diverso e
Memcheck si comporta in modo diverso da quello che farebbe per una modifica del puntatore dello stack più piccola di
soglia. Di solito questa euristica funziona bene. Tuttavia, se il tuo programma alloca grandi
strutture sullo stack, questa euristica verrà ingannata e Memcheck successivamente
segnalare un numero elevato di accessi allo stack non validi. Questa opzione consente di modificare il
soglia a un valore diverso.

Dovresti considerare l'uso di questa opzione solo se l'output di debug di Valgrind ti indirizza a
fare così. In tal caso ti dirà la nuova soglia che dovresti specificare.

In generale, allocare grandi strutture sullo stack è una cattiva idea, perché puoi
esaurire facilmente lo spazio nello stack, specialmente su sistemi con memoria limitata o che
aspettarsi di supportare un gran numero di thread ciascuno con un piccolo stack, e anche perché
il controllo degli errori eseguito da Memcheck è più efficace per i dati allocati nell'heap
rispetto ai dati allocati nello stack. Se devi usare questa opzione, potresti volerlo
considera la possibilità di riscrivere il codice per allocare sull'heap piuttosto che sullo stack.

--main-stacksize= [predefinito: uso corrente 'limitare' valore]
Specifica la dimensione dello stack del thread principale.

Per semplificare la gestione della memoria, Valgrind riserva tutto lo spazio necessario per il principale
stack del thread all'avvio. Ciò significa che deve conoscere la dimensione dello stack richiesta a
avviare.

Per impostazione predefinita, Valgrind utilizza il valore "ulimit" corrente per la dimensione dello stack, o 16 MB,
quello che è più basso. In molti casi questo fornisce una dimensione dello stack nell'intervallo da 8 a 16 MB,
che quasi mai trabocca per la maggior parte delle applicazioni.

Se hai bisogno di una dimensione dello stack più grande, usa --main-stacksize per specificarlo. Impostalo solo
quanto ti serve, dal momento che riservando molto più spazio di quello di cui hai bisogno (cioè centinaia
di megabyte in più del necessario) limita gli allocatori di memoria di Valgrind e può
ridurre la quantità totale di memoria che Valgrind può utilizzare. Questo è davvero solo di
significato su macchine a 32 bit.

Su Linux, puoi richiedere uno stack di dimensioni fino a 2 GB. Valgrind si fermerà con a
messaggio di diagnostica se non è possibile allocare lo stack.

--main-stacksize influisce solo sulla dimensione dello stack per il thread iniziale del programma. Esso ha
nessuna influenza sulla dimensione degli stack di thread, poiché Valgrind non li alloca.

Potrebbe essere necessario utilizzare entrambi --main-stacksize e --max stackframe insieme. è
importante capirlo --main-stacksize imposta la dimensione massima dello stack totale,
mentre --max stackframe specifica la dimensione più grande di qualsiasi stack frame. Desideri
devo risolvere il --main-stacksize valore per te stesso (di solito, se il tuo
segfault delle applicazioni). Ma Valgrind ti dirà il necessario --max stackframe dimensione,
se necessario.

Come discusso ulteriormente nella descrizione di --max stackframe, un requisito per un grande
stack è un segno di potenziali problemi di portabilità. Si consiglia di posizionare tutto
dati di grandi dimensioni nella memoria allocata nell'heap.

--max-threads= [predefinito: 500]
Per impostazione predefinita, Valgrind può gestire fino a 500 thread. A volte, quel numero è troppo
piccolo. Utilizzare questa opzione per fornire un limite diverso. Ad esempio --max-thread=3000.

MALLOC()-COLLEGATO VERSIONI

Per gli strumenti che utilizzano la propria versione di malloc (es. Memcheck, Massif, Helgrind, DRD), il
si applicano le seguenti opzioni.

--allineamento= [predefinito: 8 or 16 dipendente on , il piattaforma]
Di default Valgrind's malloc, rialloc, ecc, restituisce un blocco il cui indirizzo iniziale è
allineato a 8 byte o allineato a 16 byte (il valore dipende dalla piattaforma e corrisponde al
impostazione predefinita della piattaforma). Questa opzione consente di specificare un allineamento diverso. Il
il valore fornito deve essere maggiore o uguale al valore predefinito, minore o uguale a
4096 e deve essere una potenza di due.

--redzone-size= [predefinito: dipende on , il attrezzo]
di Valgrind malloc, riallocare, ecc., aggiungi blocchi di riempimento prima e dopo ogni blocco heap
assegnato dal programma in esecuzione. Tali blocchi di riempimento sono chiamati zone rosse. Il
il valore predefinito per la dimensione della zona rossa dipende dallo strumento. Ad esempio, Memcheck aggiunge e
protegge un minimo di 16 byte prima e dopo ogni blocco allocato dal client.
Ciò consente di rilevare i blocchi o gli overrun fino a 16 byte.

L'aumento delle dimensioni della zona rossa consente di rilevare superamenti di distanze maggiori,
ma aumenta la quantità di memoria utilizzata da Valgrind. La riduzione della dimensione della zona rossa lo farà
riduce la memoria necessaria a Valgrind ma riduce anche le possibilità di rilevamento
over/underruns, quindi non è raccomandato.

RARO VERSIONI

Queste opzioni si applicano a tutti gli strumenti, poiché influiscono su alcuni oscuri funzionamenti del Valgrind
nucleo. La maggior parte delle persone non avrà bisogno di usarli.

--smc-check= [predefinito: tutto-non-file da x86/amd64/s390x,
pila da Altri archi]
Questa opzione controlla il rilevamento da parte di Valgrind del codice automodificante. Se nessun controllo è
fatto, quando un programma esegue del codice, lo sovrascrive con un nuovo codice e
esegue il nuovo codice, Valgrind continuerà ad eseguire le traduzioni per cui ha effettuato
il vecchio codice. Questo probabilmente porterà a comportamenti errati e/o arresti anomali.

Per le architetture "moderne" -- tutto ciò che non è x86, amd64 o s390x -- l'impostazione predefinita
is pila. Questo perché un programma corretto deve intraprendere azioni esplicite per ristabilire
Coerenza della cache DI dopo la modifica del codice. Valgrind osserva e onora tali
azioni, con il risultato che il codice automodificante viene gestito in modo trasparente con zero
costo extra.

Per x86, amd64 e s390x, il programma non è tenuto a notificare all'hardware di
necessaria sincronizzazione della coerenza DI. Quindi l'impostazione predefinita è tutto-non-file, che copre il
caso normale di generazione di codice in un'area mmap'd anonima (non supportata da file).

I significati delle quattro impostazioni disponibili sono i seguenti. Nessun rilevamento (nessuna),
rilevare il codice automodificante nello stack (utilizzato da GCC per implementare annidato
funzioni) (pila), rileva il codice automodificante ovunque (contro tutti i), e rilevare
codice automodificante ovunque tranne che nelle mappature supportate da file (tutto-non-file).

Correndo con contro tutti i rallenterà notevolmente Valgrind. correndo con nessuna raramente
velocizzare le cose, dal momento che pochissimo codice viene generato dinamicamente nella maggior parte dei programmi.
. VALGRIND_DISCARD_TRANSLAZIONI la richiesta del cliente è un'alternativa a --smc-check=tutto
e --smc-check=tutto-non-file che richiede uno sforzo maggiore del programmatore ma consente a Valgrind
per eseguire il tuo programma più velocemente, dicendogli esattamente quando devono essere le traduzioni
rifatto.

--smc-check=tutto-non-file fornisce una versione più economica ma più limitata di
--smc-check=tutto. Aggiunge controlli a tutte le traduzioni che non provengono da
mappature della memoria supportata da file. Applicazioni tipiche che generano codice, ad esempio JIT
nei browser web, genera codice in aree mappate anonime, mentre il codice "fisso"
del browser vive sempre in mappature supportate da file. --smc-check=tutto-non-file prende
vantaggio di questa osservazione, limitando l'overhead del controllo al codice che è
probabile che sia generato da JIT.

--read-inline-info= [predefinito: vedere sotto]
Quando abilitato, Valgrind leggerà le informazioni sulle chiamate di funzione inline da DWARF3
informazioni di debug. Questo rallenta l'avvio di Valgrind e gli fa usare più memoria (in genere per
ogni pezzo di codice in linea, 6 parole e spazio per il nome della funzione), ma risulta
in stacktrace più descrittivi. Per la versione 3.10.0, questa funzionalità è abilitata
per impostazione predefinita solo per i target Linux, Android e Solaris e solo per gli strumenti
Memcheck, Helgrind e DRD. Ecco un esempio di alcuni stacktrace con
--read-inline-info=no:

==15380== Il salto o la mossa condizionale dipende da valori non inizializzati
==15380== a 0x80484EA: principale (inlinfo.c:6)
==15380==
==15380== Il salto o la mossa condizionale dipende da valori non inizializzati
==15380== a 0x8048550: fun_noninline (inlinfo.c:6)
==15380== di 0x804850E: principale (inlinfo.c:34)
==15380==
==15380== Il salto o la mossa condizionale dipende da valori non inizializzati
==15380== a 0x8048520: principale (inlinfo.c:6)

E qui ci sono gli stessi errori con --read-inline-info=sì:

==15377== Il salto o la mossa condizionale dipende da valori non inizializzati
==15377== a 0x80484EA: fun_d (inlinfo.c:6)
==15377== di 0x80484EA: fun_c (inlinfo.c:14)
==15377== di 0x80484EA: fun_b (inlinfo.c:20)
==15377== di 0x80484EA: fun_a (inlinfo.c:26)
==15377== di 0x80484EA: principale (inlinfo.c:33)
==15377==
==15377== Il salto o la mossa condizionale dipende da valori non inizializzati
==15377== a 0x8048550: fun_d (inlinfo.c:6)
==15377== di 0x8048550: fun_noninline (inlinfo.c:41)
==15377== di 0x804850E: principale (inlinfo.c:34)
==15377==
==15377== Il salto o la mossa condizionale dipende da valori non inizializzati
==15377== a 0x8048520: fun_d (inlinfo.c:6)
==15377== di 0x8048520: principale (inlinfo.c:35)

--read-var-info= [predefinito: No]
Quando abilitato, Valgrind leggerà le informazioni sui tipi di variabili e le posizioni da
Informazioni di debug di DWARF3. Questo rallenta significativamente l'avvio di Valgrind e lo rende utilizzabile
significativamente più memoria, ma per gli strumenti che possono trarne vantaggio (Memcheck,
Helgrind, DRD) può portare a messaggi di errore più precisi. Ad esempio, qui ci sono
alcuni errori standard emessi da Memcheck:

==15363== Byte non inizializzati trovati durante la richiesta di controllo del client
==15363== a 0x80484A9: gracchiare (varinfo1.c:28)
==15363== di 0x8048544: principale (varinfo1.c:55)
==15363== L'indirizzo 0x80497f7 è 7 byte all'interno del simbolo dati "global_i2"
==15363==
==15363== Byte non inizializzati trovati durante la richiesta di controllo del client
==15363== a 0x80484A9: gracchiare (varinfo1.c:28)
==15363== di 0x8048550: principale (varinfo1.c:56)
==15363== L'indirizzo 0xbea0d0cc è nello stack del thread 1
==15363== nel frame #1, creato da main (varinfo1.c:45)

E qui ci sono gli stessi errori con --read-var-info=sì:

==15370== Byte non inizializzati trovati durante la richiesta di controllo del client
==15370== a 0x80484A9: gracchiare (varinfo1.c:28)
==15370== di 0x8048544: principale (varinfo1.c:55)
==15370== La posizione 0x80497f7 è 0 byte all'interno di global_i2[7],
==15370== una variabile globale dichiarata in varinfo1.c:41
==15370==
==15370== Byte non inizializzati trovati durante la richiesta di controllo del client
==15370== a 0x80484A9: gracchiare (varinfo1.c:28)
==15370== di 0x8048550: principale (varinfo1.c:56)
==15370== La posizione 0xbeb4a0cc è 0 byte all'interno della var locale "local"
==15370== dichiarato in varinfo1.c:46, nel frame #1 del thread 1

--vgdb-poll= [predefinito: 5000]
Come parte del suo ciclo principale, lo scheduler Valgrind eseguirà il polling per verificare se alcune attività
(come un comando esterno o qualche input da un gdb) deve essere gestito da gdbserver.
Questo sondaggio di attività verrà eseguito dopo aver eseguito il numero specificato di blocchi di base (o
leggermente superiore al numero dato di blocchi di base). Questo sondaggio è abbastanza economico quindi il
il valore predefinito è impostato relativamente basso. Potresti diminuire ulteriormente questo valore se vgdb
non può usare la chiamata di sistema ptrace per interrompere Valgrind se tutti i thread sono (la maggior parte dei
tempo) bloccato in una chiamata di sistema.

--vgdb-shadow-registers=no|sì [predefinito: No]
Quando attivato, gdbserver esporrà i registri ombra Valgrind a GDB. Con questo,
il valore dei registri ombra Valgrind può essere esaminato o modificato utilizzando GDB.
L'esposizione dei registri shadow funziona solo con GDB versione 7.1 o successiva.

--vgdb-prefix= [predefinito: /tmp/vgdb-pipe]
Per comunicare con gdb/vgdb, il Valgrind gdbserver crea 3 file (2 FIFO denominati
e un file di memoria condivisa mmap). L'opzione prefisso controlla la directory e il prefisso
per la creazione di questi file.

--run-libc-freeres= [predefinito: sì]
Questa opzione è rilevante solo quando si esegue Valgrind su Linux.

La libreria GNU C (libc.so), utilizzato da tutti i programmi, può allocare memoria per
i propri usi. Di solito non si preoccupa di liberare quella memoria quando il programma finisce—
non avrebbe senso, dal momento che il kernel Linux recupera tutte le risorse del processo quando a
il processo esce comunque, quindi rallenterebbe solo le cose.

Gli autori di glibc si sono resi conto che questo comportamento causa i controllori di perdite, come Valgrind,
per segnalare erroneamente le perdite in glibc, quando viene eseguito un controllo delle perdite all'uscita. Per evitare
questo, hanno fornito una routine chiamata __libc_freeres specificamente per rilasciare glibc
tutta la memoria che ha allocato. Memcheck quindi tenta di eseguire __libc_freeres all'uscita.

Sfortunatamente, in alcune versioni molto vecchie di glibc, __libc_freeres è sufficientemente
bacato per causare errori di segmentazione. Ciò era particolarmente evidente su Red Hat 7.1.
Quindi questa opzione è fornita per inibire la corsa di __libc_freeres. Se il vostro
il programma sembra funzionare correttamente su Valgrind, ma segfaults all'uscita, potresti scoprirlo
--run-libc-freeres=no risolve che, anche se a costo di possibilmente false segnalazioni
perdite di spazio in libc.so.

--sim-suggerimento=suggerimento1,suggerimento2,...
Passa vari suggerimenti a Valgrind che modificano leggermente il comportamento simulato in
modi non standard o pericolosi, possibilmente per aiutare la simulazione di strane caratteristiche. Di
di default nessun suggerimento è abilitato. Usare con cautela! I suggerimenti attualmente noti sono:

· lax-ioctl: Sii molto lassista riguardo alla gestione di ioctl; l'unica ipotesi è che la dimensione
è corretta. Non richiede l'inizializzazione dell'intero buffer durante la scrittura.
Senza questo, usando alcuni driver di dispositivo con un gran numero di strani ioctl
i comandi diventano molto noiosi.

· compatibile con fusibile: Abilita la gestione speciale per alcune chiamate di sistema che potrebbero bloccarsi
in un file system FUSE. Questo potrebbe essere necessario quando si esegue Valgrind su a
programma multi-thread che utilizza un thread per gestire un file system FUSE e
un altro thread per accedere a quel file system.

· abilita-esterno: Abilita alcune magie speciali necessarie quando il programma in esecuzione è
stesso Valgrind.

· nessun-prefisso-interno: Disabilitare la stampa di un prefisso > davanti a ogni stdout o stderr
linea di uscita in un Valgrind interno gestito da un Valgrind esterno. Questo è utile
durante l'esecuzione di test di regressione Valgrind in una configurazione esterna/interna. Nota che il
prefisso > sarà sempre stampato davanti alle righe interne di registrazione del debug.

· no-nptl-pthread-stackcache: Questo suggerimento è rilevante solo quando si esegue Valgrind su
Linux.

La libreria GNU glibc pthread (libpthread.so), utilizzato dai programmi pthread,
mantiene una cache di stack di pthread. Quando un pthread termina, la memoria utilizzata
per lo stack pthread e alcune strutture dati relative all'archiviazione locale del thread non lo sono
sempre rilasciato direttamente. Questa memoria è conservata in una cache (fino a una certa dimensione),
e viene riutilizzato se viene avviato un nuovo thread.

Questa cache fa sì che lo strumento helgrind riporti alcune condizioni di gara false positive
errori su questa memoria cache, poiché helgrind non comprende la glibc interna
primitive di sincronizzazione della cache. Quindi, quando si utilizza Helgrind, disabilitare la cache
aiuta ad evitare condizioni di gara false positive, in particolare quando si utilizza il thread
variabili di memorizzazione locale (ad es. variabili che utilizzano il __filo qualificatore).

Quando si utilizza lo strumento memcheck, disabilitare la cache garantisce la memoria utilizzata da glibc
per gestire le variabili __thread viene rilasciato direttamente quando un thread termina.

Nota: Valgrind disabilita la cache utilizzando alcune conoscenze interne dello stack glibc
implementazione della cache ed esaminando le informazioni di debug del pthread
biblioteca. Questa tecnica è quindi alquanto fragile e potrebbe non funzionare per tutti glibc
versioni. Questoèstato testato con successo con varie versioni di glibc (es
2.11, 2.16, 2.18) su varie piattaforme.

· porte lassiste: (Solo Solaris) Sii molto lassista riguardo alla gestione delle chiamate di sistema della porta
descrittori di file porta non riconosciuti. Non richiede che il buffer pieno sia
inizializzato durante la scrittura. Senza questo, i programmi che utilizzano libdoor(3LIB) funzionalità
con semantica completamente proprietaria può segnalare un numero elevato di falsi positivi.

--fair-sched= [predefinito: No]
. --programmato opzione controlla il meccanismo di blocco utilizzato da Valgrind per serializzare
esecuzione del filo. Il meccanismo di blocco controlla il modo in cui i thread sono pianificati,
e le diverse impostazioni offrono diversi compromessi tra equità e prestazioni. Per
maggiori dettagli sullo schema di serializzazione del thread Valgrind e il suo impatto su
prestazioni e pianificazione dei thread, vedere Pianificazione e prestazioni multi-thread.

· Il valore --fair-sched=sì attiva uno schedulatore equo. In breve, se multiplo
i thread sono pronti per essere eseguiti, i thread verranno pianificati in modo round robin.
Questo meccanismo non è disponibile su tutte le piattaforme o versioni Linux. Altrimenti
disponibile, utilizzando --fair-sched=sì farà terminare Valgrind con un errore.

Potresti scoprire che questa impostazione migliora la reattività generale se stai eseguendo un
programma multithread interattivo, ad esempio un browser Web, su Valgrind.

· Il valore --fair-sched=prova attiva una programmazione equa se disponibile sulla piattaforma.
In caso contrario, tornerà automaticamente a --fair-sched=n.

· Il valore --fair-sched=n attiva uno schedulatore che non garantisce l'equità
tra i thread pronti per essere eseguiti, ma che in generale offre le prestazioni più elevate.

--kernel-variant=variante1,variante2,...
Gestire le chiamate di sistema e ioctls derivanti da varianti minori del kernel predefinito per
questa piattaforma. Questo è utile per l'esecuzione su kernel compromessi o con moduli del kernel
che supportano ioctls non standard, per esempio. Usare con cautela. se non lo fai
capisci cosa fa questa opzione, quindi quasi sicuramente non ne hai bisogno. Attualmente
varianti conosciute sono:

· bproc: sostenere il sys_broc chiamata di sistema su x86. Questo è per l'esecuzione su BProc,
che è una variante minore di Linux standard che viene talvolta utilizzata per la compilazione
cluster.

· android-no-hw-tls: alcune versioni dell'emulatore Android per ARM non forniscono a
registro hardware TLS (thread-local state) e Valgrind si blocca all'avvio. Utilizzo
questa variante per selezionare il supporto software per TLS.

· android-gpu-sgx5xx: usalo per supportare la gestione di ioctls proprietari per il
Serie di GPU PowerVR SGX 5XX su dispositivi Android. La mancata selezione di questo non lo fa
causare problemi di stabilità, ma può far sì che Memcheck riporti falsi errori dopo il
programma esegue ioctls specifici per GPU.

· android-gpu-adreno3xx: allo stesso modo, usa questo per supportare la gestione dei proprietari
ioctls per la serie di GPU Qualcomm Adreno 3XX su dispositivi Android.

--merge-recursive-frames= [predefinito: 0]
Alcuni algoritmi ricorsivi, ad esempio implementazioni di alberi binari bilanciati, creano
molte tracce di stack differenti, ciascuna contenente cicli di chiamate. Un ciclo è definito come
due valori di contatore di programma identici separati da zero o più altri contatori di programma
valori. Valgrind può quindi utilizzare molta memoria per memorizzare tutte queste tracce dello stack. Questo è
un cattivo uso della memoria considerando che tali tracce di stack contengono ripetute non interessanti
chiamate ricorsive invece di informazioni più interessanti come la funzione che ha
avviato la chiamata ricorsiva.

L'opzione --merge-recursive-frames= istruisce Valgrind a rilevare e fondere
cicli di chiamata ricorsivi aventi una dimensione fino a cornici. Quando un tale ciclo è
rilevato, Valgrind registra il ciclo nella traccia dello stack come un contatore di programma univoco.

Il valore 0 (predefinito) non causa l'unione di chiamate ricorsive. Un valore di 1 causerà
stack trace di semplici algoritmi ricorsivi (ad esempio, un'implementazione fattoriale)
essere crollato. Di solito è necessario un valore 2 per comprimere le tracce dello stack prodotte
da algoritmi ricorsivi come alberi binari, ordinamento rapido, ecc. Potrebbero essere valori più alti
necessario per algoritmi ricorsivi più complessi.

Nota: le chiamate ricorsive vengono rilevate dall'analisi dei valori del contatore del programma. Non sono
rilevato guardando i nomi delle funzioni.

--num-transtab-settori= [predefinito: 6 da Android piattaforme, 16 da contro tutti i altri]
Valgrind traduce e strumenta il codice macchina del tuo programma in piccoli frammenti
(blocchi di base). Le traduzioni sono memorizzate in una cache di traduzione che è divisa
in una serie di sezioni (settori). Se la cache è piena, il settore contenente il
le traduzioni più vecchie vengono svuotate e riutilizzate. Se queste vecchie traduzioni sono necessarie di nuovo,
Valgrind deve ritradurre e ristrumentare il codice macchina corrispondente, che è
caro. Se il working set delle "istruzioni eseguite" di un programma è grande, crescente
il numero di settori può migliorare le prestazioni riducendo il numero di
necessarie ritraduzioni. I settori sono assegnati su richiesta. Una volta allocato, un settore può
non essere mai liberato, e occupa uno spazio considerevole, a seconda dello strumento e del valore
of --avg-transtab-dimensione-voce (circa 40 MB per settore per Memcheck). Usa l'opzione
--stats=sì ottenere informazioni precise sulla memoria utilizzata da un settore e sul
allocazione e riciclo dei settori.

--avg-transtab-entry-size= [predefinito: 0, significato uso purché predefinito]
Dimensione media del blocco di base tradotto. Questa dimensione media viene utilizzata per dimensionare il
dimensione di un settore. Ciascuno strumento fornisce un valore predefinito da utilizzare. Se questo valore predefinito
è troppo piccolo, i settori della traduzione si riempiranno troppo rapidamente. Se questa impostazione predefinita
valore è troppo grande, una parte significativa della memoria del settore di traduzione sarà inutilizzata.
Nota che la dimensione media di una traduzione di blocchi di base dipende dallo strumento e potrebbe
dipendono dalle opzioni dello strumento. Ad esempio, l'opzione memcheck --track-origins=sì aumenta
la dimensione delle traduzioni di blocco di base. Utilizzo --avg-transtab-dimensione-voce per sintonizzare il
dimensione dei settori, sia per guadagnare memoria sia per evitare troppe ritraduzioni.

--aspace-minaddr= [predefinito: dipende on , il piattaforma]
Per evitare potenziali conflitti con alcune librerie di sistema, Valgrind non utilizza il
spazio degli indirizzi qui sotto --aspace-minadr valore, mantenendolo riservato nel caso in cui una libreria
richiede specificamente la memoria in questa regione. Quindi, si ipotizza un valore "pessimistico"
da Valgrind a seconda della piattaforma. Su Linux, per impostazione predefinita, Valgrind evita di usare il
primi 64 MB anche se in genere non c'è conflitto in questa zona completa. Puoi usare
l'opzione --aspace-minadr per far beneficiare la tua applicazione affamata di memoria
più di questa memoria inferiore. D'altra parte, se incontri un conflitto, aumentando
Il valore aspace-minaddr potrebbe risolverlo. I conflitti si manifestano in genere con
errori di mmap nell'intervallo basso dello spazio degli indirizzi. L'indirizzo fornito deve essere page
allineato e deve essere uguale o maggiore a 0x1000 (4KB). Per trovare il valore predefinito sul tuo
piattaforma, fai qualcosa come valgrind -d -d date 2>&1 | grep -i minaddr. Valori
inferiore a 0x10000 (64KB) sono noti per creare problemi su alcune distribuzioni.

--valgrind-stacksize= [predefinito: 1 MB]
Per ogni thread, Valgrind necessita del proprio stack "privato". La dimensione predefinita per questi
stacks è ampiamente dimensionato e quindi dovrebbe essere sufficiente nella maggior parte dei casi. Nel caso in cui
la dimensione è troppo piccola, Valgrind segfault. Prima di eseguire il segfault, potrebbe essere visualizzato un avviso
prodotto da Valgrind quando ci si avvicina al limite.

Usa l'opzione --valgrind-stacksize se viene prodotto un tale (improbabile) avvertimento, o
Valgrind muore a causa di una violazione della segmentazione. Tali violazioni della segmentazione sono state
visto quando si smontano enormi simboli C++.

Se la tua applicazione utilizza molti thread e richiede molta memoria, puoi ottenerne un po'
memoria riducendo la dimensione di questi stack Valgrind utilizzando l'opzione
--valgrind-stacksize.

--show-emwarns= [predefinito: No]
Quando abilitato, Valgrind emetterà avvisi sulla sua emulazione della CPU in alcuni casi.
Questi di solito non sono interessanti.

--require-text-symbol=:sonnamepatt:fnnamepatt
Quando un oggetto condiviso il cui soname corrisponde sonamepatt viene caricato nel processo,
esaminare tutti i simboli di testo che esporta. Se nessuno di questi corrisponde fnnapatt, stampa e
messaggio di errore e abbandonare la corsa. Ciò consente di garantire che la corsa non
non continuare a meno che un dato oggetto condiviso non contenga un particolare nome di funzione.

Entrambi sonamepatt e fnnapatt può essere scritto usando il solito ? e * caratteri jolly. Per
esempio: ":*libc.so*:foo?bar". Puoi usare caratteri diversi dai due punti per separare
i due modelli. È importante solo che il primo carattere e il separatore
carattere sono gli stessi. Ad esempio, l'esempio precedente potrebbe anche essere scritto
"Q*libc.so*Qfoo?bar". multiplo
--require-testo-simbolo i flag sono consentiti, nel qual caso gli oggetti condivisi che vengono caricati
nel processo verrà verificato rispetto a tutti loro.

Lo scopo è supportare l'utilizzo affidabile delle librerie contrassegnate. Per esempio,
supponiamo di avere una versione di GCC libgomp.so che è stato contrassegnato con
annotazioni per supportare Helgrind. È fin troppo facile e confuso caricare l'errore,
non annotato libgomp.so nell'applicazione. Quindi l'idea è: aggiungi un simbolo di testo nel
libreria contrassegnata, per esempio annotato_for_helgrind_3_6, e poi dai la bandiera
--require-text-symbol=:*libgomp*so*:annotated_for_helgrind_3_6 in modo che quando libgomp.so
è caricato, Valgrind scansiona la sua tabella dei simboli, e se il simbolo non è presente l'esecuzione è
interrotto, invece di continuare in silenzio con la libreria non contrassegnata. Nota che tu
dovrebbe mettere l'intero flag tra virgolette per fermare le conchiglie che si espandono verso l'alto * e ?
caratteri jolly.

--soname-sinonimi=syn1=schema1,syn2=schema2,...
Quando viene caricata una libreria condivisa, Valgrind controlla le funzioni nella libreria che
deve essere sostituito o avvolto. Ad esempio, Memcheck sostituisce tutti i relativi a malloc
funzioni (malloc, free, calloc, ...) con le proprie versioni. Tali sostituzioni sono
fatto per impostazione predefinita solo nelle librerie condivise il cui soname corrisponde a un soname predefinito
modello (es libc.so* su Linux). Per impostazione predefinita, non viene eseguita alcuna sostituzione per uno statico
libreria collegata o per librerie alternative come tcmalloc. In alcuni casi, il
le sostituzioni consentono --soname-sinonimi per specificare un modello di sinonimo aggiuntivo, dando
flessibilità nella sostituzione.

Attualmente, questa flessibilità è consentita solo per le funzioni relative a malloc, utilizzando
il sinonimo somaloc. Questo sinonimo è utilizzabile per tutti gli strumenti che eseguono la sostituzione standard
di funzioni relative a malloc (es. memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Libreria malloc alternativa: per sostituire le funzioni relative a malloc in una alternativa
libreria con soname mymalloclib.so, dai l'opzione
--soname-sinonimi=somalloc=mymalloclib.so. Un modello può essere utilizzato per abbinare più
sonomi delle biblioteche. Per esempio, --soname-sinonimi=somalloc=*tcmalloc* corrisponderà
il nome di tutte le varianti della libreria tcmalloc (nativa, debug, profilata, ...
varianti tcmalloc).

Nota: il soname di una libreria condivisa da elfi può essere recuperato utilizzando readelf
utilità.

· Le sostituzioni in una libreria collegata staticamente vengono eseguite utilizzando il NONE pattern.
Ad esempio, se ti colleghi con libtcmalloc.a, memcheck funzionerà correttamente quando tu
dai la possibilità --soname-sinonimi=somalloc=NESSUNO. Nota che un pattern NONE lo farà
abbinare l'eseguibile principale e qualsiasi libreria condivisa senza soname.

· Per eseguire una build di Firefox "predefinita" per Linux, in cui JEMalloc è collegato al
eseguibile principale, usa --soname-sinonimi=somalloc=NESSUNO.

DEBUG VALGRIND VERSIONI

Ci sono anche alcune opzioni per il debug di Valgrind stesso. Non dovresti aver bisogno di usarli
nel normale svolgimento delle cose. Se desideri vedere l'elenco, usa il --help-debug opzione.

MEM CHECK VERSIONI

--leak-check= [predefinito: riepilogo]
Se abilitato, cerca le perdite di memoria al termine del programma client. Se impostato su
sommario, dice quante perdite si sono verificate. Se impostato su pieno or sì, ogni singola perdita
verrà mostrato in dettaglio e/o conteggiato come errore, come specificato dalle opzioni
--show-leak-tipi e --errors-for-leak-tipi.

--leak-resolution= [predefinito: alto]
Quando si esegue il controllo delle perdite, determina quanto Memcheck è disposto a considerare diversi
i backtrace siano gli stessi allo scopo di unire più perdite in un unico
rapporto di fuga. Quando impostato su Basso, solo le prime due voci devono corrispondere. quando di, quattro
le voci devono corrispondere. quando alto, tutte le voci devono corrispondere.

Per il debug di perdite hardcore, probabilmente vorrai usare --leak-resolution=alta insieme
con --num-chiamanti=40 o un numero così grande.

Notare quello --risoluzione perdite l'impostazione non influisce sulla capacità di Memcheck di trovare
perdite. Cambia solo il modo in cui vengono presentati i risultati.

--show-leak-kinds= [predefinito: definito, possibile]
Specifica i tipi di perdite da mostrare in a pieno ricerca perdite, in uno dei seguenti modi:

· un elenco separato da virgole di uno o più di definito indiretto possibile raggiungibile.

· contro tutti i per specificare il set completo (tutti i tipi di perdite). È equivalente a
--show-leak-kinds=definito,indiretto,possibile,raggiungibile.

· nessuna per l'insieme vuoto

--errors-for-leak-kinds= [predefinito: definito, possibile]
Specifica i tipi di perdite da contare come errori in a pieno ricerca di perdite. Il is
specificato in modo simile a --show-leak-tipi

--leak-check-heuristics= [predefinito: Tutti]
Specifica il set di euristiche di controllo delle perdite da utilizzare durante le ricerche delle perdite. Il
l'euristica controlla quali puntatori interni a un blocco fanno sì che venga considerato come
raggiungibile. L'insieme euristico viene specificato in uno dei seguenti modi:

· un elenco separato da virgole di uno o più di stringa standard lunghezza64 nuova matrice
eredità multipla.

· contro tutti i per attivare il set completo di euristiche. È equivalente a
--leak-check-heuristics=stdstring,length64,newarray,ereditarietà multipla.

· nessuna per l'insieme vuoto

Si noti che queste euristiche dipendono dal layout degli oggetti prodotti dal
compilatore C++. Sono stati testati con alcune versioni di gcc (es. 4.4 e 4.7). Essi
potrebbe non funzionare correttamente con altri compilatori C++.

--show-reachable= , --show-possibilmente-perso=
Queste opzioni forniscono un modo alternativo per specificare i tipi di perdite da mostrare:

· --show-raggiungibile=n --mostra-possibilmente-perso=sì è equivalente
--show-leak-kinds=definito,possibile.

· --show-raggiungibile=n --mostra-possibilmente-perso=no è equivalente
--show-leak-kinds=definito.

· --show-reachable=sì è equivalente --show-leak-kinds=tutto.

Si noti che --mostra-possibilmente-perso=no non ha effetto se --show-reachable=sì è specificato.

--undef-value-errors= [predefinito: sì]
Controlla se i report Memcheck utilizzano errori di valore non definito. Imposta questo su no if
non vuoi vedere errori di valore non definito. Ha anche l'effetto collaterale dell'eccesso di velocità
su Memcheck un po'.

--track-origins= [predefinito: No]
Controlla se Memcheck tiene traccia dell'origine dei valori non inizializzati. Per impostazione predefinita, è
non lo fa, il che significa che sebbene possa dirti che un valore non inizializzato è
essere usato in modo pericoloso, non può dirti dove è arrivato il valore non inizializzato
a partire dal. Questo spesso rende difficile rintracciare il problema alla radice.

Quando impostato su sì, Memcheck tiene traccia delle origini di tutti i valori non inizializzati.
Quindi, quando viene segnalato un errore di valore non inizializzato, Memcheck proverà a mostrare il
origine del valore. Un'origine può essere uno dei quattro posti seguenti: un blocco heap,
un'allocazione dello stack, una richiesta del client o varie altre fonti (ad es. una chiamata a
brk).

Per i valori non inizializzati provenienti da un blocco heap, Memcheck mostra dove il blocco
è stato assegnato. Per i valori non inizializzati provenienti da un'allocazione dello stack, Memcheck
può dirti quale funzione ha assegnato il valore, ma non di più - in genere è
mostra la posizione di origine della parentesi graffa di apertura della funzione. Quindi dovresti
controlla attentamente che tutte le variabili locali della funzione siano inizializzate correttamente.

Sovraccarico delle prestazioni: il monitoraggio dell'origine è costoso. Dimezza la velocità di Memcheck e
aumenta l'utilizzo della memoria di un minimo di 100 MB e possibilmente di più. Tuttavia può
ridurre drasticamente lo sforzo necessario per identificare la causa principale dei problemi di inizializzazione
errori di valore, e così spesso è una vittoria in termini di produttività del programmatore, nonostante l'esecuzione di più
lentamente.

Precisione: Memcheck tiene traccia delle origini in modo abbastanza accurato. Per evitare spazio e tempo molto grandi
spese generali, vengono fatte alcune approssimazioni. È possibile, anche se improbabile, che
Memcheck segnalerà un'origine errata o non sarà in grado di identificare alcuna origine.

Nota che la combinazione --track-origins=sì e --undef-value-errors=no is
insensato. Memcheck verifica e rifiuta questa combinazione all'avvio.

--carichi-parziali-ok= [predefinito: sì]
Controlla il modo in cui Memcheck gestisce i carichi allineati naturalmente a 32, 64, 128 e 256 bit da
indirizzi per cui alcuni byte sono indirizzabili e altri no. quando sì, come
i carichi non producono un errore di indirizzo. Invece, byte caricati provenienti da illegal
gli indirizzi sono contrassegnati come non inizializzati e quelli corrispondenti a indirizzi legali sono
gestita nel modo normale.

Quando no, i carichi da indirizzi parzialmente non validi sono trattati come i carichi da
indirizzi completamente non validi: viene emesso un errore di indirizzo illegale e il conseguente
i byte sono contrassegnati come inizializzati.

Nota che il codice che si comporta in questo modo viola gli standard ISO C/C++,
e dovrebbe essere considerato rotto. Se possibile, tale codice dovrebbe essere corretto.

--expensive-definedness-checks= [predefinito: No]
Controlla se Memcheck dovrebbe impiegare più precisi ma anche più costosi (tempo
consumo) algoritmi durante il controllo della definizione di un valore. L'impostazione predefinita è
non farlo e di solito è sufficiente. Tuttavia, per codice altamente ottimizzato
valgrind può a volte lamentarsi erroneamente. Invocare valgrind con
--expensive-definedness-checks=sì aiuta ma ha un costo in termini di prestazioni. Tempo di esecuzione
è stato osservato un degrado del 25% ma il costo aggiuntivo dipende molto dal
applicazione a portata di mano.

--keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|nessuno [predefinito:
alloc-and-free]
Controlla quali tracce impilate da conservare per i blocchi malloc'd e/o free'd.

Con alloc-allora-libero, viene registrata una traccia dello stack al momento dell'allocazione ed è associata
con il blocco. Quando il blocco viene liberato, viene registrata una seconda traccia dello stack e questo
sostituisce la traccia dello stack di allocazione. Di conseguenza, qualsiasi errore "use after free" relativo a
a questo blocco può mostrare solo una traccia dello stack per dove è stato liberato il blocco.

Con alloc-and-free, sia l'allocazione che le tracce dello stack di deallocazione per il blocco
sono immagazzinati. Quindi un errore "use after free" mostrerà entrambi, il che potrebbe causare l'errore
più facile da diagnosticare. Rispetto a alloc-allora-libero, questa impostazione aumenta leggermente
L'uso della memoria di Valgrind poiché il blocco contiene due riferimenti invece di uno.

Con allocare, viene registrata (e segnalata) solo la traccia dello stack di allocazione. Insieme a gratuita,
viene registrata (e segnalata) solo la traccia dello stack di deallocazione. Questi valori un po'
diminuire la memoria di Valgrind e l'utilizzo della CPU. Possono essere utili a seconda dell'errore
tipi che stai cercando e il livello di dettaglio necessario per analizzarli. Per
esempio, se sei interessato solo agli errori di perdita di memoria, è sufficiente registrare
le tracce dello stack di allocazione.

Con nessuna, non vengono registrate tracce dello stack per le operazioni malloc e libere. Se tuo
il programma alloca molti blocchi e/o alloca/libera da molti stack differenti
tracce, questo può ridurre significativamente la CPU e/o la memoria richiesta. Certo, pochi
verranno riportati i dettagli per gli errori relativi ai blocchi heap.

Si noti che una volta registrata una traccia dello stack, Valgrind mantiene la traccia dello stack in memoria
anche se non è referenziato da alcun blocco. Alcuni programmi (ad esempio ricorsivo
algoritmi) possono generare un numero enorme di tracce di stack. Se Valgrind ne usa troppo
memoria in tali circostanze, è possibile ridurre la memoria richiesta con le opzioni
--keep-stacktraces e/o utilizzando un valore inferiore per l'opzione --num-chiamanti.

--freelist-vol= [predefinito: 20000000]
Quando il programma client rilascia memoria utilizzando gratuita (in C) o cancellare (C++), quella memoria
non è immediatamente disponibile per la riassegnazione. Invece, è segnato
inaccessibili e posti in una coda di blocchi liberati. Lo scopo è quello di rinviare finché
possibile il punto in cui la memoria liberata torna in circolazione. Questo
aumenta la possibilità che Memcheck sia in grado di rilevare accessi non validi ai blocchi
per un certo periodo di tempo dopo che sono stati liberati.

Questa opzione specifica la dimensione totale massima, in byte, dei blocchi nella coda.
Il valore predefinito è venti milioni di byte. Aumentando questo aumenta l'importo totale
di memoria utilizzata da Memcheck ma potrebbe rilevare utilizzi non validi dei blocchi liberati che sarebbero
altrimenti passa inosservato.

--freelist-big-blocks= [predefinito: 1000000]
Quando si rendono disponibili per la riallocazione i blocchi dalla coda dei blocchi liberati,
Memcheck farà ricircolare prioritariamente i blocchi di dimensione maggiore o uguale a
--freelist-grandi-blocchi. Questo assicura che liberando grossi blocchi (in particolare liberando
blocchi più grandi di --freelist-vol) non comporta immediatamente un ricircolo di
tutti (o molti) i piccoli blocchi nell'elenco libero. In altre parole, questa opzione
aumenta anche la probabilità di scoprire puntatori penzolanti per i blocchi "piccoli"
quando vengono liberati grossi blocchi.

L'impostazione di un valore di 0 significa che tutti i blocchi vengono ricircolati in un ordine FIFO.

--workaround-gcc296-bugs= [predefinito: No]
Quando abilitato, supponi che legga e scriva a una piccola distanza sotto il puntatore dello stack
sono dovuti a bug in GCC 2.96 e non li segnala. La "piccola distanza" è 256
byte per impostazione predefinita. Nota che GCC 2.96 è il compilatore predefinito su alcuni antichi Linux
distribuzioni (RedHat 7.X) e quindi potrebbe essere necessario utilizzare questa opzione. Non usarlo se
non è necessario, poiché può far passare inosservati errori reali. Un'alternativa migliore
consiste nell'usare un GCC più recente in cui questo bug è stato corretto.

Potrebbe essere necessario utilizzare questa opzione anche quando si lavora con GCC 3.X o 4.X a 32 bit
PowerPC Linux. Questo perché GCC genera codice che occasionalmente accede di seguito
il puntatore dello stack, in particolare per le conversioni in virgola mobile da/verso interi. Questo
è in violazione della specifica PowerPC ELF a 32 bit, che non prevede alcuna disposizione per
posizioni sotto il puntatore dello stack per essere accessibili.

--show-mismatched-frees= [predefinito: sì]
Quando abilitato, Memcheck controlla che i blocchi heap siano deallocati usando una funzione che
corrisponde alla funzione di assegnazione. Cioè, si aspetta gratuita da usare per deallocare
blocchi allocati da malloc, delete per i blocchi assegnati da nuovie Elimina[] da
blocchi allocati da nuovo[]. Se viene rilevata una mancata corrispondenza, viene segnalato un errore. Questo è in
generale importante perché in alcuni ambienti, liberando con una funzione non abbinata
può causare arresti anomali.

Esiste tuttavia uno scenario in cui tali discrepanze non possono essere evitate. Questo è quando il
l'utente fornisce implementazioni di nuovi/nuovo[] quella chiamata malloc e di delete/Elimina[]
quella chiamata gratuitae queste funzioni sono inline in modo asimmetrico. Ad esempio, immagina
che Elimina[] è in linea ma nuovo[] non è. Il risultato è che Memcheck "vede" tutto
Elimina[] chiamate come chiamate dirette a gratuita, anche quando la sorgente del programma non contiene
chiamate non corrispondenti.

Ciò causa molti rapporti di errore confusi e irrilevanti.
--show-mismatched-frees=no disabilita questi controlli. Non è generalmente consigliabile
disabilitarli, tuttavia, perché di conseguenza potresti perdere errori reali.

--ignore-intervalli=0xPP-0xQQ[,0xRR-0xSS]
Qualsiasi intervallo elencato in questa opzione (e possono essere specificati più intervalli, separati da
virgole) verranno ignorate dal controllo di indirizzabilità di Memcheck.

--maloc-fill=
Riempie i blocchi allocati da malloc, new, ecc., ma non da calloc, con lo specificato
byte. Questo può essere utile quando si cerca di eliminare oscuri problemi di corruzione della memoria.
L'area assegnata è ancora considerata da Memcheck come indefinita -- solo questa opzione
influenza il suo contenuto. Notare che --malloc-riempimento non influisce su un blocco di memoria quando
viene utilizzato come argomento per le richieste del client VALGRIND_MEMPOOL_ALLOC o
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill=
Riempie i blocchi liberati da free, delete, ecc. con il valore di byte specificato. Questo può essere
utile quando si cerca di eliminare oscuri problemi di corruzione della memoria. L'area liberata è
ancora considerato da Memcheck come non valido per l'accesso -- questa opzione ha effetto solo sul suo
Contenuti. Notare che --riempimento libero non influisce su un blocco di memoria quando viene utilizzato come
argomento alle richieste client VALGRIND_MEMPOOL_FREE o VALGRIND_FREELIKE_BLOCK.

CACHEGRIND VERSIONI

--I1= , , dimensione>
Specificare la dimensione, l'associatività e la dimensione della linea della cache delle istruzioni di livello 1.

--D1= , , dimensione>
Specificare la dimensione, l'associatività e la dimensione della linea della cache di dati di livello 1.

--LL= , , dimensione>
Specificare la dimensione, l'associatività e la dimensione della linea della cache di ultimo livello.

--cache-sim=no|sì [sì]
Abilita o disabilita la raccolta di accessi alla cache e conteggi mancati.

--branch-sim=no|sì [No]
Abilita o disabilita la raccolta di istruzioni di salto e conteggi errati. Di
di default questo è disabilitato in quanto rallenta Cachegrind di circa il 25%. Notare che
non puoi specificare --cache-sim=no e --ramo-sim=n insieme, come se ne andrebbe
Cachegrind senza informazioni da raccogliere.

--cachegrind-out-file=
Scrivi i dati del profilo su un file anziché sul file di output predefinito,
cachegrind.out. . Il %p e %q gli identificatori di formato possono essere utilizzati per incorporare il processo
ID e/o il contenuto di una variabile d'ambiente nel nome, come nel caso di
opzione principale --file-log.

CHIAMATA VERSIONI

--callgrind-out-file=
Scrivi i dati del profilo su un file anziché sul file di output predefinito,
callgrind.out. . Il %p e %q gli identificatori di formato possono essere utilizzati per incorporare il processo
ID e/o il contenuto di una variabile d'ambiente nel nome, come nel caso di
opzione principale --file-log. Quando vengono effettuati più dump, il nome del file viene modificato
ulteriore; vedi sotto.

--dump-line= [predefinito: sì]
Specifica che il conteggio degli eventi deve essere eseguito con la granularità della riga di origine.
Ciò consente l'annotazione della fonte per le fonti che sono compilate con informazioni di debug
(-g).

--dump-instr= [predefinito: No]
Ciò specifica che il conteggio degli eventi deve essere eseguito con la granularità per istruzione.
Ciò consente l'annotazione del codice assembly. Attualmente i risultati possono essere solo visualizzati
di KCachegrind.

--compress-strings= [predefinito: sì]
Questa opzione influenza il formato di output dei dati del profilo. Specifica se
le stringhe (nomi di file e funzioni) devono essere identificate da numeri. Questo riduce il
file, ma rende più difficile la lettura per gli umani (cosa sconsigliata in nessuno
Astuccio).

--compress-pos= [predefinito: sì]
Questa opzione influenza il formato di output dei dati del profilo. Specifica se
le posizioni numeriche sono sempre specificate come valori assoluti o possono essere
rispetto ai numeri precedenti. Questo riduce la dimensione del file.

--combine-dump= [predefinito: No]
Quando abilitato, quando devono essere generate più parti di dati del profilo, queste parti sono
aggiunto allo stesso file di output. Non consigliato.

--dump-ogni-bb= [predefinito: 0, mai]
Scarica i dati del profilo ogni contare blocchi di base. Se è necessario un dump è solo controllato
quando viene eseguito lo scheduler interno di Valgrind. Pertanto, l'impostazione minima utile è
circa 100000. Il conteggio è un valore a 64 bit per rendere possibili lunghi periodi di dump.

--dump-before=
Scarica quando entri funzione.

--zero-before=
Azzera tutti i costi quando entri funzione.

--dump-after=
Scarica quando esci funzione.

--instr-atstart= [predefinito: sì]
Specificare se si desidera che Callgrind avvii la simulazione e la profilazione dall'inizio del
il programma. Se impostato su no, Callgrind non sarà in grado di raccogliere alcuna informazione,
comprese le chiamate, ma avrà al massimo un rallentamento intorno a 4, che è il minimo
Valgrind sopra la testa. La strumentazione può essere abilitata in modo interattivo tramite callgrind_control
-io su.

Nota che il grafico delle chiamate risultante molto probabilmente non conterrà principale, ma lo farà
contengono tutte le funzioni eseguite dopo l'abilitazione della strumentazione. Strumentazione
può anche essere abilitato/disabilitato a livello di codice. Vedere il file include Callgrind callgrind.h
per la macro che devi usare nel tuo codice sorgente.

Per la simulazione della cache, i risultati saranno meno accurati all'accensione della strumentazione
più avanti nell'esecuzione del programma, poiché in quel momento il simulatore si avvia con una cache vuota.
Attiva la raccolta eventi in un secondo momento per far fronte a questo errore.

--collect-atstart= [predefinito: sì]
Specificare se la raccolta eventi è abilitata all'inizio dell'esecuzione del profilo.

Per guardare solo parti del tuo programma, hai due possibilità:

1. Azzerare i contatori di eventi prima di accedere alla parte di programma che si desidera profilare e scaricare
l'evento conta su un file dopo aver lasciato quella parte di programma.

2. Attiva/disattiva lo stato di raccolta in base alle esigenze per visualizzare solo i contatori di eventi in corso
mentre all'interno della parte di programma che si desidera profilare.

La seconda opzione può essere utilizzata se la parte del programma che si desidera profilare è chiamata many
volte. L'opzione 1, ovvero la creazione di molti dump non è pratica qui.

Lo stato della raccolta può essere commutato all'ingresso e all'uscita di una determinata funzione con l'opzione
--toggle-collezione. Se usi questa opzione, lo stato della raccolta dovrebbe essere disabilitato al
inizio. Si noti che la specifica di --toggle-collezione implicitamente imposta
--collect-state=no.

Lo stato della raccolta può essere commutato anche inserendo la richiesta del cliente
CALLGRIND_TOGGLE_COLLECT ; nelle posizioni di codice necessarie.

--toggle-collect=
Attiva/disattiva la raccolta all'ingresso/uscita di funzione.

--collect-jumps= [predefinito: No]
Specifica se devono essere raccolte le informazioni per i salti (condizionali). Come
sopra, callgrind_annotate attualmente non è in grado di mostrarti i dati. Devi usare
KCachegrind per ottenere le frecce di salto nel codice annotato.

--collect-systime= [predefinito: No]
Specifica se devono essere raccolte le informazioni per i tempi delle chiamate di sistema.

--collect-bus= [predefinito: No]
Specifica se il numero di eventi bus globali eseguiti deve essere raccolto.
Per questi eventi viene utilizzato il tipo di evento "Ge".

--cache-sim= [predefinito: No]
Specificare se si desidera eseguire la simulazione della cache completa. Per impostazione predefinita, viene letta solo l'istruzione
verranno conteggiati gli accessi ("Ir"). Con la simulazione della cache, ulteriori contatori di eventi sono
abilitato: Cache miss su letture istruzioni ("I1mr"/"ILmr"), accessi in lettura dati ("Dr")
e relativi cache miss ("D1mr"/"DLmr"), accessi in scrittura dati ("Dw") e relativa cache
manca ("D1mw"/"DLmw"). Per ulteriori informazioni, vedere Cachegrind: una cache e branch-
profilatore di previsione

--branch-sim= [predefinito: No]
Specificare se si desidera eseguire la simulazione della previsione del ramo. Ulteriori contatori di eventi sono
abilitato: numero di rami condizionali eseguiti e relativi fallimenti predittivi
("Bc"/"Bcm"), salti indiretti eseguiti e relativi mancati del predittore dell'indirizzo di salto
("Bi"/"Bim").

HELGRIND VERSIONI

--free-is-write=no|sì [predefinito: No]
Quando abilitato (non di default), Helgrind tratta la liberazione della memoria heap come se
la memoria è stata scritta immediatamente prima di quella libera. Questo espone le gare dove c'è la memoria
referenziato da un thread e liberato da un altro, ma non è osservabile
evento di sincronizzazione per garantire che il riferimento avvenga prima del libero.

Questa funzionalità è nuova in Valgrind 3.7.0 ed è considerata sperimentale. è
non abilitato per impostazione predefinita perché la sua interazione con gli allocatori di memoria personalizzati non lo è
ben compreso al momento. Il feedback degli utenti è il benvenuto.

--track-lockorders=no|sì [predefinito: sì]
Quando abilitato (impostazione predefinita), Helgrind esegue il controllo della coerenza dell'ordine di blocco. Per
alcuni programmi difettosi, il gran numero di errori di ordine di blocco segnalati può diventare
fastidioso, in particolare se sei interessato solo agli errori di gara. Puoi quindi
trova utile disabilitare il controllo dell'ordine di blocco.

--history-level=none|circa|pieno [predefinito: completo]
--history-level=pieno (l'impostazione predefinita) fa sì che Helgrind raccolga abbastanza informazioni su
"vecchi" accessi che possono produrre due tracce di stack in un rapporto di gara - sia lo stack
traccia per l'accesso corrente e traccia per l'accesso precedente in conflitto. Per
limitare l'utilizzo della memoria, le tracce dello stack degli accessi "vecchi" sono limitate a un massimo di 8 voci,
anche se --num-chiamanti il valore è maggiore.

La raccolta di tali informazioni è costosa sia in termini di velocità che di memoria, in particolare per
programmi che eseguono molti eventi di sincronizzazione tra thread (blocchi, sblocchi, ecc.).
Senza tali informazioni, è più difficile rintracciare le cause profonde delle gare.
Tuttavia, potresti non averne bisogno in situazioni in cui vuoi solo controllare il
presenza o assenza di razze, ad esempio, quando si eseguono test di regressione di a
programma precedentemente senza gare.

--history-level=nessuno è l'estremo opposto. Fa sì che Helgrind non ne raccolga nessuno
informazioni sugli accessi precedenti. Questo può essere notevolmente più veloce di
--history-level=pieno.

--history-level=approssimativamente fornisce un compromesso tra questi due estremi. Causa
Helgrind per mostrare una traccia completa per l'accesso successivo e informazioni approssimative
per quanto riguarda l'accesso anticipato. Queste informazioni approssimative sono costituite da due pile e
è garantito che l'accesso precedente sia avvenuto da qualche parte tra i punti del programma
indicato dalle due pile. Questo non è utile come mostrare lo stack esatto per il
accesso precedente (come --history-level=pieno fa), ma è meglio di niente, ed è
è quasi veloce come --history-level=nessuno.

--conflitto-dimensione-cache=N [predefinito: 1000000]
Questo flag ha effetto solo su --history-level=pieno.

Le informazioni sui "vecchi" accessi in conflitto sono memorizzate in una cache di dimensioni limitate,
con gestione in stile LRU. Questo è necessario perché non è pratico conservare a
traccia dello stack per ogni singolo accesso alla memoria effettuato dal programma. Informazioni storiche
su posizioni non di recente accesso viene periodicamente scartato, per liberare spazio nel
cache.

Questa opzione controlla la dimensione della cache, in termini di numero di memoria diversa
indirizzi per i quali sono archiviate informazioni di accesso in conflitto. Se lo trovi
Helgrind mostra errori di gara con un solo stack invece dei due previsti
stack, prova ad aumentare questo valore.

Il valore minimo è 10,000 e il massimo è 30,000,000 (trenta volte il valore predefinito
valore). Aumentando il valore di 1, il fabbisogno di memoria di Helgrind aumenta di molto
circa 100 byte, quindi il valore massimo consumerà facilmente tre gigabyte in più o giù di lì
di memoria.

--check-stack-refs=no|sì [predefinito: sì]
Per impostazione predefinita, Helgrind controlla tutti gli accessi alla memoria dati effettuati dal tuo programma. questa bandiera
consente di saltare il controllo degli accessi agli stack di thread (variabili locali). questo può
migliorare le prestazioni, ma a scapito delle gare mancanti sui dati allocati in stack.

--ignore-thread-creation= [predefinito: No]
Controlla se tutte le attività durante la creazione del thread devono essere ignorate. Per impostazione predefinita
abilitato solo su Solaris. Solaris offre maggiore produttività, parallelismo e
scalabilità rispetto ad altri sistemi operativi, al costo di un blocco più dettagliato
attività. Ciò significa ad esempio che quando viene creato un thread sotto glibc, solo uno
big lock viene utilizzato per tutte le impostazioni del thread. La libc Solaris utilizza diversi blocchi a grana fine
e il thread creatore riprende le sue attività il prima possibile, uscendo ad esempio
stack e sequenza di installazione TLS nel thread creato. Questa situazione confonde Helgrind
poiché presuppone che ci sia un falso ordinamento in atto tra creatore e creato
filo; e quindi molti tipi di condizioni di gara nell'applicazione non sarebbero
segnalato. Per prevenire tale falso ordinamento, questa opzione della riga di comando è impostata su yes da
predefinito su Solaris. Tutte le attività (carichi, negozi, richieste dei clienti) vengono quindi ignorate
durante:

· chiamata pthread_create() nel thread del creatore

· fase di creazione del thread (stack e configurazione TLS) nel thread creato

Anche la nuova memoria allocata durante la creazione del thread non viene tracciata, ovvero i rapporti sulla gara
è soppresso lì. DRD fa implicitamente la stessa cosa. Questo è necessario perché
La libc di Solaris memorizza nella cache molti oggetti e li riutilizza per diversi thread e questo
confonde l'Helgrind.

DRD VERSIONI

--check-stack-var= [predefinito: No]
Controlla se DRD rileva corse di dati sulle variabili dello stack. Verifica delle variabili dello stack
è disabilitato per impostazione predefinita perché la maggior parte dei programmi non condivide le variabili dello stack su
thread.

--exclusive-soglia= [predefinito: spento]
Stampa un messaggio di errore se un blocco mutex o writer è stato mantenuto più a lungo del tempo
specificato in millisecondi. Questa opzione consente il rilevamento di conflitti di blocco.

--join-list-vol= [predefinito: 10]
Corse di dati che si verificano tra un'istruzione alla fine di un thread e un altro thread
può essere perso se le informazioni sull'accesso alla memoria vengono scartate immediatamente dopo che un thread ha
stato unito. Questa opzione permette di specificare per quanti thread uniti la memoria
le informazioni di accesso devono essere conservate.

--first-race-only= [predefinito: No]
Se riportare solo la prima corsa di dati che è stata rilevata su una posizione di memoria
o tutte le corse di dati che sono state rilevate su una posizione di memoria.

--free-is-write= [predefinito: No]
Se segnalare le gare tra l'accesso alla memoria e la liberazione della memoria. Abilitazione di questo
L'opzione potrebbe rallentare leggermente l'esecuzione di DRD. Appunti:

· Non abilitare questa opzione quando si utilizzano allocatori di memoria personalizzati che utilizzano il
VG_USERREQ__MALLOCLIKE_BLOCK e VG_USERREQ__FREELIKE_BLOCK perché
provocare falsi positivi.

· Non abilitare questa opzione quando si utilizzano oggetti conteggiati per riferimento perché lo farà
provocare falsi positivi, anche quando quel codice è stato annotato correttamente con
ANNOTATE_HAPPENS_BEFORE e ANNOTATE_HAPPENS_AFTER. Vedi ad esempio l'output di
il seguente comando per un esempio: valgrind --tool=drd --free-is-write=yes
drd/tests/annotate_smart_pointer.

--report-signal-unlocked= [predefinito: sì]
Se segnalare le chiamate a pthread_cond_signal e pthread_cond_broadcast dove
mutex associato al segnale attraverso pthread_cond_wait or
pthread_cond_timed_waitnon è bloccato al momento dell'invio del segnale. Invio di un segnale
senza tenere un blocco sul mutex associato è un errore di programmazione comune che può
causare condizioni di gara sottili e comportamenti imprevedibili. Esistono alcuni non comuni
modelli di sincronizzazione tuttavia dove è sicuro inviare un segnale senza tenere a
bloccare il mutex associato.

--segment-merging= [predefinito: sì]
Controlla l'unione dei segmenti. La fusione dei segmenti è un algoritmo per limitare l'utilizzo della memoria del
algoritmo di rilevamento della corsa dei dati. La disabilitazione dell'unione dei segmenti può migliorare la precisione di
i cosiddetti 'altri segmenti' visualizzati nei rapporti di gara ma possono anche attivare un out
di errore di memoria.

--segment-merging-interval= [predefinito: 10]
Esegui l'unione dei segmenti solo dopo che il numero specificato di nuovi segmenti è stato
creato. Questa è un'opzione di configurazione avanzata che consente di scegliere se
ridurre al minimo l'utilizzo della memoria di DRD scegliendo un valore basso o per consentire a DRD di funzionare più velocemente di
scegliendo un valore leggermente più alto. Il valore ottimale per questo parametro dipende dal
programma in analisi. Il valore predefinito funziona bene per la maggior parte dei programmi.

--soglia-condivisa= [predefinito: spento]
Stampa un messaggio di errore se un blocco del lettore è stato trattenuto più a lungo del tempo specificato
(in millisecondi). Questa opzione consente il rilevamento di conflitti di blocco.

--show-confl-seg= [predefinito: sì]
Mostra segmenti in conflitto nei rapporti di gara. Poiché queste informazioni possono aiutare a trovare il
causa di una corsa di dati, questa opzione è abilitata per impostazione predefinita. La disabilitazione di questa opzione rende
l'output di DRD più compatto.

--show-stack-usage= [predefinito: No]
Stampa l'utilizzo dello stack al momento dell'uscita del thread. Quando un programma crea un gran numero di
thread diventa importante limitare la quantità di memoria virtuale allocata per
pile di fili. Questa opzione consente di osservare quanta memoria dello stack è stata
utilizzato da ogni thread del programma client. Nota: lo stesso strumento DRD assegna alcuni
dati temporanei nello stack di thread del client. Lo spazio necessario per questi dati temporanei
deve essere allocato dal programma client quando alloca la memoria dello stack, ma non lo è
incluso nell'utilizzo dello stack riportato da DRD.

--ignore-thread-creation= [predefinito: No]
Controlla se tutte le attività durante la creazione del thread devono essere ignorate. Per impostazione predefinita
abilitato solo su Solaris. Solaris offre maggiore produttività, parallelismo e
scalabilità rispetto ad altri sistemi operativi, al costo di un blocco più dettagliato
attività. Ciò significa ad esempio che quando viene creato un thread sotto glibc, solo uno
big lock viene utilizzato per tutte le impostazioni del thread. La libc Solaris utilizza diversi blocchi a grana fine
e il thread creatore riprende le sue attività il prima possibile, uscendo ad esempio
stack e sequenza di installazione TLS nel thread creato. Questa situazione confonde DRD in quanto
presuppone che ci sia un falso ordinamento in atto tra il creatore e il thread creato; e
pertanto molti tipi di race condition nell'applicazione non verrebbero riportati. Per
impedire tale falso ordinamento, questa opzione della riga di comando è impostata su sì per impostazione predefinita su
Solaris. Tutte le attività (carichi, negozi, richieste dei clienti) vengono quindi ignorate durante:

· chiamata pthread_create() nel thread del creatore

· fase di creazione del thread (stack e configurazione TLS) nel thread creato

--trace-addr= [predefinito: nessuno]
Traccia tutte le attività di caricamento e archiviazione per l'indirizzo specificato. Questa opzione potrebbe essere
specificato più di una volta.

--ptrace-addr= [predefinito: nessuno]
Traccia tutte le attività di caricamento e archiviazione per l'indirizzo specificato e continua a farlo anche
dopo che la memoria a quell'indirizzo è stata liberata e riallocata.

--trace-alloc= [predefinito: No]
Traccia tutte le allocazioni e deallocazioni di memoria. Può produrre una quantità enorme di output.

--trace-barriera= [predefinito: No]
Traccia tutta l'attività della barriera.

--trace-cond= [predefinito: No]
Traccia tutte le attività delle variabili di condizione.

--trace-fork-join= [predefinito: No]
Traccia tutta la creazione del thread e tutti gli eventi di terminazione del thread.

--trace-hb= [predefinito: No]
Traccia l'esecuzione di ANNOTATE_HAPPENS_BEFORE(), ANNOTATE_HAPPENS_AFTER() e
ANNOTATE_HAPPENS_DONE() richieste del client.

--trace-mutex= [predefinito: No]
Traccia tutta l'attività del mutex.

--trace-rwlock= [predefinito: No]
Traccia tutta l'attività di blocco lettore-scrittore.

--trace-semaphore= [predefinito: No]
Traccia tutta l'attività del semaforo.

MASSICCIO VERSIONI

--heap= [predefinito: sì]
Specifica se deve essere eseguita la profilatura dell'heap.

--heap-admin= [predefinito: 8]
Se la profilazione dell'heap è abilitata, fornisce il numero di byte amministrativi per blocco a
utilizzo. Questa dovrebbe essere una stima della media, poiché può variare. Ad esempio, il
l'allocatore usato da glibc su Linux richiede da 4 a 15 byte per blocco,
a seconda di vari fattori. Quell'allocatore richiede anche spazio amministratore per essere liberato
blocchi, ma Massif non può spiegarlo.

--stack= [predefinito: No]
Specifica se deve essere eseguita la profilatura dello stack. Questa opzione rallenta Massif
notevolmente, e quindi è disattivato per impostazione predefinita. Nota che Massif assume che lo stack principale abbia
dimensione zero all'avvio. Questo non è vero, ma fare diversamente con precisione è difficile.
Inoltre, partire da zero indica meglio la dimensione della parte dello stack principale
su cui un programma utente ha effettivamente il controllo.

--pages-as-heap= [predefinito: No]
Dice a Massif di profilare la memoria a livello di pagina piuttosto che al blocco malloc
livello. Vedi sopra per i dettagli.

--profondità= [predefinito: 30]
Profondità massima degli alberi di allocazione registrati per snapshot dettagliati. aumentandolo
farà funzionare Massif un po' più lentamente, utilizzerà più memoria e produrrà un output più grande
File.

--alloc-fn=
Le funzioni specificate con questa opzione verranno trattate come se fossero un mucchio
funzione di allocazione come malloc. Questo è utile per le funzioni che sono wrapper per
malloc or nuovi, che può riempire gli alberi di allocazione con informazioni non interessanti.
Questa opzione può essere specificata più volte sulla riga di comando, per nominare più volte
funzioni.

Nota che la funzione denominata saràtrattata in questo modo solo seèla prima voce in a
stack trace, o appena sotto un'altra funzione trattata in questo modo. Ad esempio, se hai
una funzione malloc1 che avvolge malloce malloc2 che avvolge malloc1, solo specificando
--alloc-fn=malloc2 non avrà alcun effetto. Devi specificare --alloc-fn=malloc1 as
bene. Questo è un po' scomodo, ma il motivo è che controllare l'allocazione
funzioni è lento e fa risparmiare molto tempo se Massif può smettere di guardare attraverso
impilare le voci di traccia non appena ne trova una che non corrisponde invece di doverla fare
continuare attraverso tutte le voci.

Nota che i nomi C++ sono smantellati. Nota anche che i nomi C++ sovraccaricati devono essere scritti
in toto. Potrebbero essere necessarie virgolette singole per evitare che la shell le spezzi.
Per esempio:

--alloc-fn='operator new(unsigned, std::nothrow_t const&)'

--ignore-fn=
Qualsiasi allocazione diretta dell'heap (cioè una chiamata a malloc, nuovi, ecc, o una chiamata a una funzione
chiamato da an --alloc-fn opzione) che si verifica in una funzione specificata da questa opzione will
essere ignorato. Questo è principalmente utile per scopi di test. Questa opzione può essere specificata
più volte sulla riga di comando, per denominare più funzioni.

Qualsiasi rialloc di un blocco ignorato verrà ignorato, anche se il rialloc chiamare
non si verificano in una funzione ignorata. Ciò evita la possibilità di dimensioni heap negative
se i blocchi ignorati vengono ridotti con rialloc.

Le regole per scrivere i nomi delle funzioni C++ sono le stesse di --alloc-fn sopra.

--soglia= [predefinito: 1.0]
La soglia di significatività per le allocazioni dell'heap, come percentuale della dimensione totale della memoria.
Le voci dell'albero di allocazione che rappresentano un valore inferiore verranno aggregate. Notare che
questo dovrebbe essere specificato in tandem con l'opzione di ms_print con lo stesso nome.

--peak-inaccuracy= [predefinito: 1.0]
Massif non registra necessariamente l'effettivo picco di allocazione della memoria globale; di
di default registra un picco solo quando la dimensione di allocazione della memoria globale supera la
picco precedente di almeno l'1.0%. Questo perché ci possono essere molte allocazioni locali
picchi lungo la strada, e fare un'istantanea dettagliata per ognuno sarebbe costoso
e dispendioso, poiché tutti tranne uno verranno successivamente scartati. Questa imprecisione può essere
modificato (anche a 0.0%) tramite questa opzione, ma Massif funzionerà drasticamente più lentamente poiché
numero tende a zero.

--unità-tempo= [predefinito: i]
L'unità di tempo utilizzata per la profilazione. Ci sono tre possibilità: istruzioni
eseguito (i), che è buono per la maggior parte dei casi; tempo reale (orologio da parete) (ms, cioè
millisecondi), che a volte è utile; e byte allocati/deallocati nell'heap
e/o stack (B), che è utile per programmi a esecuzione molto breve e per i test
scopi, perché è il più riproducibile su macchine diverse.

--freq-dettagliata= [predefinito: 10]
Frequenza delle istantanee dettagliate. Insieme a --freq-dettagliata=1, ogni istantanea è dettagliata.

--max-snapshots= [predefinito: 100]
Il numero massimo di istantanee registrate. Se impostato su N, per tutti i programmi tranne very
quelli di breve durata, il numero finale di istantanee sarà compreso tra N/2 e N.

--massif-out-file= [predefinito: massiccio.fuori.%p]
Scrivi i dati del profilo su un file anziché sul file di output predefinito,
massiccio.fuori. . Il %p e %q gli identificatori di formato possono essere utilizzati per incorporare l'ID del processo
e/o il contenuto di una variabile d'ambiente nel nome, come nel caso di
opzione principale --file-log.

SGCHECK VERSIONI

Al momento non sono disponibili opzioni della riga di comando specifiche per SGCheck.

BBV VERSIONI

--bb-out-file= [predefinito: bb.out.%p]
Questa opzione seleziona il nome del file vettoriale del blocco di base. Il %p e %q formato
gli specificatori possono essere utilizzati per incorporare l'ID del processo e/o il contenuto di un ambiente
variabile nel nome, come nel caso dell'opzione core --file-log.

--pc-out-file= [predefinito: PC.out.%p]
Questa opzione seleziona il nome del file PC. Questo file contiene gli indirizzi del contatore del programma
e informazioni sul nome della funzione per i vari blocchi di base. Questo può essere usato insieme
con il file vettoriale del blocco di base per avanzare rapidamente tramite i nomi delle funzioni anziché solo
l'istruzione conta. Il %p e %q gli identificatori di formato possono essere utilizzati per incorporare il processo
ID e/o il contenuto di una variabile d'ambiente nel nome, come nel caso di
opzione principale --file-log.

--dimensione-intervallo= [predefinito: 100000000]
Questa opzione seleziona la dimensione dell'intervallo da utilizzare. Il valore predefinito è 100 milioni
istruzioni, che è un valore comunemente usato. È possibile utilizzare altre dimensioni; più piccoli
gli intervalli possono aiutare i programmi con fasi a grana più fine. Tuttavia, dimensione dell'intervallo più piccola
può portare a problemi di precisione a causa degli effetti di riscaldamento (quando si avanza velocemente tra i vari
le caratteristiche architettoniche non saranno inizializzate e sarà necessario un certo numero di
istruzioni prima che si "scaldino" allo stato in cui una simulazione completa sarebbe senza
l'avanzamento veloce. Intervalli di grandi dimensioni tendono a mitigare questo problema.)

--instr-count-only [predefinito: No]
Questa opzione indica allo strumento di visualizzare solo i totali del conteggio delle istruzioni e di no
generare il file vettoriale del blocco di base effettivo. Questo è utile per il debug e per
raccogliere informazioni sul conteggio delle istruzioni senza generare il grande vettore di blocchi di base
File.

LACCHÈ VERSIONI

--basic-counts= [predefinito: sì]
Quando abilitato, Lackey stampa le seguenti statistiche e informazioni sul
esecuzione del programma client:

1. Il numero di chiamate alla funzione specificata dal --fnnome opzione (l'impostazione predefinita
è principale). Se al programma sono stati eliminati i simboli, il conteggio sarà sempre
zero.

2. Il numero di rami condizionati incontrati e il numero e la proporzione di
quelli presi.

3. Il numero di superblocchi immessi e completati dal programma. Nota che a causa di
ottimizzazioni fatte dalla SIC, questo non è affatto un valore accurato.

4. Il numero di istruzioni guest (x86, amd64, ppc, ecc.) e dichiarazioni IR
eseguito. IR è la rappresentazione intermedia simile a RISC di Valgrind attraverso la quale all
la strumentazione è fatta.

5. Rapporti tra alcuni di questi conteggi.

6. Il codice di uscita del programma client.

--detailed-counts= [predefinito: No]
Quando abilitato, Lackey stampa una tabella contenente conteggi di carichi, negozi e ALU
operazioni, differenziate per i loro tipi di IR. I tipi IR sono identificati dal loro IR
nome ("I1", "I8", ... "I128", "F32", "F64" e "V128").

--trace-mem= [predefinito: No]
Quando abilitato, Lackey stampa la dimensione e l'indirizzo di quasi tutti gli accessi alla memoria effettuati da
il programma. Vedere i commenti nella parte superiore del file lackey/lk_main.c per i dettagli
sul formato di output, su come funziona e sulle imprecisioni nella traccia dell'indirizzo. Nota
che questa opzione produce enormi quantità di output.

--trace-superblocks= [predefinito: No]
Quando abilitato, Lackey stampa l'indirizzo di ogni superblocco (una singola voce,
uscita multipla, blocco lineare di codice) eseguito dal programma. Questo è principalmente di
interesse per gli sviluppatori Valgrind. Vedi i commenti all'inizio del file
lackey/lk_main.c per i dettagli sul formato di output. Nota che questa opzione produce
grandi quantità di output.

--fnname= [predefinito: principale]
Modifica la funzione per la quale vengono conteggiate le chiamate quando --basic-counts=sì è specificato.

Utilizza valgrind.bin online utilizzando i servizi onworks.net