valgrind.bin - Online en la nube

PROGRAMA:

NOMBRE

valgrind: un conjunto de herramientas para depurar y crear perfiles de programas

SINOPSIS

Valgrind [valgrind-opciones] [tu-programa] [sus-opciones-de-programa]

DESCRIPCIÓN

Valgrind es un programa flexible para depurar y perfilar ejecutables de Linux. Consiste
de un núcleo, que proporciona una CPU sintética en software, y una serie de depuración y
herramientas de perfilado. La arquitectura es modular, por lo que se pueden crear nuevas herramientas fácilmente y
sin perturbar la estructura existente.

Algunas de las opciones que se describen a continuación funcionan con todas las herramientas de Valgrind, y algunas solo funcionan con
unos pocos o uno. La sección OPCIONES DE MEMCHECK y las que se encuentran debajo describen herramientas específicas.
.

Esta página de manual cubre solo el uso básico y las opciones. Para obtener información más completa,
consulte la documentación HTML en su sistema:
$ INSTALL / share / doc / valgrind / html / index.html, o en línea:
http://www.valgrind.org/docs/manual/index.html.

HERRAMIENTA SELECCIÓN OPCIONES

La opción más importante.

--tool = [defecto: verificación de memoria]
Ejecute la herramienta Valgrind llamada nombre de la herramienta, por ejemplo, memcheck, cachegrind, callgrind, helgrind,
drd, macizo, lacayo, ninguno, exp-sgcheck, exp-bbv, exp-dhat, etc.

ED. BÁSICA OPCIONES

Estas opciones funcionan con todas las herramientas.

-h --ayuda
Muestra ayuda para todas las opciones, tanto para el núcleo como para la herramienta seleccionada. Si la opcion
se repite es equivalente a dar --ayuda-depuración.

--ayuda-depuración
Igual que --ayuda, pero también enumera las opciones de depuración que, por lo general, solo sirven para
Desarrolladores de Valgrind.

--versión
Muestra el número de versión del núcleo de Valgrind. Las herramientas pueden tener su propia versión
números. Existe un esquema para garantizar que las herramientas solo se ejecuten cuando el núcleo
es una versión con la que se sabe que trabajan. Esto se hizo para minimizar las posibilidades de
problemas extraños que surgen de incompatibilidades entre versiones de herramientas y núcleos.

-q, --tranquilo
Ejecute silenciosamente y solo imprima mensajes de error. Útil si está ejecutando regresión
pruebas o tener alguna otra maquinaria de prueba automatizada.

-v, --verboso
Sea más detallado. Brinda información adicional sobre varios aspectos de su programa, como:
los objetos compartidos cargados, las supresiones utilizadas, el progreso de la instrumentación
y motores de ejecución, y advertencias sobre comportamientos inusuales. Repitiendo la opción
aumenta el nivel de verbosidad.

--trace-children = [defecto: No]
Cuando está habilitado, Valgrind rastreará los subprocesos iniciados a través del ejecutivo te
llama. Esto es necesario para programas multiproceso.

Tenga en cuenta que Valgrind se remonta al hijo de un tenedor (sería difícil no hacerlo,
desde tenedor hace una copia idéntica de un proceso), por lo que esta opción es posiblemente mala
llamado. Sin embargo, la mayora de los nios de tenedor llamadas llamar inmediatamente ejecutivo de todos modos.

--trace-children-skip = patt1, patt2, ...
Esta opción solo tiene efecto cuando --trace-children = sí está especificado. Permite
algunos niños se saltan. La opción toma una lista de patrones separados por comas para
los nombres de los ejecutables secundarios que Valgrind no debe rastrear. Los patrones pueden
incluir los metacaracteres? y *, que tienen el significado habitual.

Esto puede resultar útil para podar ramas poco interesantes de un árbol de procesos que se
ejecutar en Valgrind. Pero debes tener cuidado al usarlo. Cuando Valgrind se salta el rastreo
en un ejecutable, no solo omite el seguimiento de ese ejecutable, también omite
rastreando cualquiera de los procesos secundarios de ese ejecutable. En otras palabras, la bandera no
simplemente hace que el rastreo se detenga en los ejecutables especificados; omite el rastreo de
subárboles de proceso completo arraigados en cualquiera de los ejecutables especificados.

--trace-children-skip-by-arg = patt1, patt2, ...
Esto es lo mismo que --trace-niños-saltar, con una diferencia: la decisión de
si rastrear en un proceso hijo se hace examinando los argumentos al niño
proceso, en lugar del nombre de su ejecutable.

--child-silent-after-fork = [defecto: No]
Cuando está habilitado, Valgrind no mostrará ninguna salida de depuración o registro para el niño
proceso resultante de un tenedor llama. Esto puede hacer que la salida sea menos confusa (aunque
más engañoso) cuando se trata de procesos que crean niños. Es particularmente
útil junto con --trace-children =. El uso de esta opción también se
recomendado si está solicitando salida XML (--xml = sí), ya que de lo contrario el XML de
el niño y el padre pueden confundirse, lo que generalmente lo hace inútil.

--vgdb = [defecto: sí]
Valgrind proporcionará la funcionalidad "gdbserver" cuando --vgdb = sí or --vgdb = completo is
especificado. Esto permite que un depurador GNU GDB externo controle y depure su programa
cuando se ejecuta en Valgrind. --vgdb = completo incurre en gastos generales de rendimiento significativos, pero
proporciona puntos de interrupción y puntos de observación más precisos. Consulte Depurar su programa usando
Gdbserver y GDB de Valgrind para una descripción detallada.

Si el gdbserver incorporado está habilitado pero no se está utilizando ningún gdb actualmente, el vgdb
La utilidad de línea de comandos puede enviar "comandos de monitorización" a Valgrind desde un shell. los
El núcleo de Valgrind proporciona un conjunto de comandos de monitor de Valgrind. Una herramienta puede opcionalmente
Proporcionar comandos de monitor específicos de la herramienta, que están documentados en la herramienta específica.
.

--vgdb-error = [defecto: 999999999]
Utilice esta opción cuando Valgrind gdbserver esté habilitado con --vgdb = sí or --vgdb = completo.
Las herramientas que notifican errores esperarán a que se notifiquen los errores "numéricos" antes de congelarse
el programa y esperando que se conecte con GDB. De ello se deduce que un valor de cero
hará que gdbserver se inicie antes de que se ejecute su programa. Este es
normalmente se utiliza para insertar puntos de interrupción de GDB antes de la ejecución, y también funciona con herramientas
que no reportan errores, como Massif.

--vgdb-stop-at = [defecto: ninguno]
Utilice esta opción cuando Valgrind gdbserver esté habilitado con --vgdb = sí or --vgdb = completo.
Se invocará Valgrind gdbserver para cada error después --vgdb-error han sido
informó. Además, puede solicitar que se invoque Valgrind gdbserver para otros
eventos, especificados de una de las siguientes formas:

· Una lista separada por comas de uno o más de inicio salida valgrindabexit.

Los valores inicio salida valgrindabexit respectivamente, indique para invocar gdbserver
antes de que se ejecute su programa, después de la última instrucción de su programa, en
Salida anormal de Valgrind (por ejemplo, error interno, memoria insuficiente, ...).

Nota: inicio y --vgdb-error = 0 ambos harán que se invoque Valgrind gdbserver
antes de que se ejecute su programa. los --vgdb-error = 0 además causará tu
programa para detenerse en todos los errores posteriores.

· all para especificar el conjunto completo. Es equivalente a
--vgdb-stop-at = inicio, salida, valgrindabexit.

· ninguna para el conjunto vacío.

--track-fds = [defecto: No]
Cuando está habilitado, Valgrind imprimirá una lista de descriptores de archivos abiertos al salir o al
solicitud, a través del comando gdbserver monitor v.info abrir_fds. Junto con cada archivo
el descriptor se imprime un seguimiento de la pila de dónde se abrió el archivo y cualquier detalle
relacionados con el descriptor de archivo, como el nombre del archivo o los detalles del socket.

- sello de tiempo = [defecto: No]
Cuando está habilitado, cada mensaje está precedido por una indicación del reloj de pared transcurrido
tiempo desde el inicio, expresado en días, horas, minutos, segundos y milisegundos.

--log-fd = [defecto: 2, estándar]
Especifica que Valgrind debe enviar todos sus mensajes al archivo especificado
descriptor. El valor predeterminado, 2, es el canal de error estándar (stderr). Tenga en cuenta que esto puede
interferir con el uso de stderr por parte del cliente, ya que la salida de Valgrind será
intercalado con cualquier salida que el cliente envíe a stderr.

--log-file =
Especifica que Valgrind debe enviar todos sus mensajes al archivo especificado. Si el
El nombre del archivo está vacío, provoca un aborto. Hay tres especificadores de formato especiales que
se puede utilizar en el nombre del archivo.

%p se reemplaza con el ID de proceso actual. Esto es muy útil para programas que
invocar múltiples procesos. ADVERTENCIA: Si usa --trace-children = sí y tu programa
invoca múltiples procesos O su programa se bifurca sin llamar a exec después, y
no usa este especificador (o el %q especificador a continuación), la salida de Valgrind de todos
esos procesos irán a un solo archivo, posiblemente mezclados y posiblemente incompletos.

% q {FOO} se reemplaza con el contenido de la variable de entorno FOO. Si el {FOO}
parte está mal formada, provoca un aborto. Este especificador rara vez se necesita, pero muy
útil en determinadas circunstancias (por ejemplo, cuando se ejecutan programas MPI). La idea es que tu
especificar una variable que se establecerá de manera diferente para cada proceso en el trabajo, para
ejemplo BPROC_RANK o lo que sea aplicable en su configuración de MPI. Si el nombrado
La variable de entorno no está establecida, provoca un aborto. Tenga en cuenta que en algunas conchas, el {
y } Es posible que sea necesario escapar de los caracteres con una barra invertida.

%% se reemplaza con %.

Si un % va seguido de cualquier otro carácter, provoca un aborto.

Si el nombre del archivo especifica un nombre de archivo relativo, se coloca en la inicial del programa.
directorio de trabajo: este es el directorio actual cuando el programa inició su
ejecución después de la bifurcación o después de la ejecución. Si especifica un nombre de archivo absoluto (es decir.
comienza con '/') luego se coloca allí.

--log-socket =
Especifica que Valgrind debe enviar todos sus mensajes al puerto especificado en el
dirección IP especificada. El puerto puede omitirse, en cuyo caso se utiliza el puerto 1500. Si un
la conexión no se puede hacer al socket especificado, Valgrind vuelve a escribir
salida al error estándar (stderr). Esta opción está pensada para ser utilizada en
junto con el programa valgrind-listener. Para obtener más detalles, consulte el
comentario en el manual.

RELACIONADO CON ERRORES OPCIONES

Estas opciones son utilizadas por todas las herramientas que pueden informar errores, por ejemplo, Memcheck, pero no
caché.

--xml = [defecto: No]
Cuando está habilitado, las partes importantes de la salida (por ejemplo, mensajes de error de la herramienta) estarán en
Formato XML en lugar de texto sin formato. Además, la salida XML se enviará a un
canal de salida diferente al de la salida de texto sin formato. Por lo tanto, también debe usar uno
of --xml-fd, - archivo -xml or --xml-zócalo para especificar dónde se enviará el XML.

Los mensajes menos importantes se seguirán imprimiendo en texto sin formato, pero debido a que el XML
La salida y la salida de texto sin formato se envían a diferentes canales de salida (el destino de
la salida de texto sin formato todavía está controlada por --log-fd, --archivo de registro y --zócalo de registro)
esto no debería causar problemas.

Esta opción tiene como objetivo facilitar la vida de las herramientas que consumen la salida de Valgrind como
entrada, como interfaces GUI. Actualmente esta opción funciona con Memcheck, Helgrind,
DRD y SGcheck. El formato de salida se especifica en el archivo.
docs / internals / xml-output-protocol4.txt en el árbol de fuentes de Valgrind 3.5.0 o
más tarde.

Las opciones recomendadas para que pase una GUI, al solicitar una salida XML, son: --xml = sí
para habilitar la salida XML, - archivo -xml para enviar la salida XML a un (presumiblemente seleccionado por GUI)
archivo, --archivo de registro para enviar la salida de texto sin formato a un segundo archivo seleccionado por GUI,
--child-silent-after-fork = síy -q para restringir la salida de texto sin formato a crítica
mensajes de error creados por el propio Valgrind. Por ejemplo, no leer una especificación
archivo de supresiones cuenta como un mensaje de error crítico. De esta manera, para una exitosa
ejecutar el archivo de salida de texto estará vacío. Pero si no está vacío, contendrá
información importante que el usuario de la GUI debe conocer.

--xml-fd = [defecto: -1, discapacitado]
Especifica que Valgrind debe enviar su salida XML al descriptor de archivo especificado.
Debe utilizarse junto con --xml = sí.

- archivo-xml =
Especifica que Valgrind debe enviar su salida XML al archivo especificado. Debe ser
utilizado junto con --xml = sí. Alguna %p or %q secuencias que aparecen en el nombre del archivo
se expanden exactamente de la misma manera que para --archivo de registro. Ver la descripcion
of --archivo de registro para obtener más detalles.

--xml-socket =
Especifica que Valgrind debe enviar su salida XML al puerto especificado en el
Dirección IP. Debe utilizarse junto con --xml = sí. La forma del argumento es
el mismo que el usado por --zócalo de registro. Ver la descripción de --zócalo de registro para más
Detalles.

--xml-user-comment =
Inserta una cadena de comentario de usuario adicional al comienzo de la salida XML. Solo funciona cuando
--xml = sí está especificado; ignorado de lo contrario.

--demangle = [defecto: sí]
Habilita / deshabilita la demanda automática (decodificación) de nombres C ++. Habilitado por defecto. Cuando
habilitado, Valgrind intentará traducir los nombres codificados en C ++ a algo
acercándose al original. El demangler maneja los símbolos destrozados por las versiones 2.X de g ++,
3.X y 4.X.

Un hecho importante sobre la demanda es que los nombres de funciones mencionados en las supresiones
los archivos deben estar en su forma destrozada. Valgrind no exige nombres de funciones cuando
buscando las supresiones aplicables, porque hacer lo contrario haría que la supresión
el contenido del archivo depende del estado de la maquinaria de demanda de Valgrind, y también
coincidencia de supresión descendente.

--num-callers = [defecto: 12]
Especifica el número máximo de entradas que se muestran en los seguimientos de la pila que identifican el programa.
ubicaciones. Tenga en cuenta que los errores son comunes utilizando solo las cuatro ubicaciones de funciones principales
(el lugar en la función actual y el de sus tres llamantes inmediatos). Así que esto
no afecta el número total de errores informados.

El valor máximo para esto es 500. Tenga en cuenta que una configuración más alta hará que Valgrind ejecute un
un poco más lento y requiere un poco más de memoria, pero puede ser útil cuando se trabaja con
programas con cadenas de llamadas profundamente anidadas.

--unw-stack-scan-thresh = [defecto: 0] , --unw-stack-scan-frames = [defecto:
5]
La compatibilidad con el escaneo de pilas solo está disponible en objetivos ARM.

Estos indicadores permiten y controlan el desenrollado de la pila mediante el escaneo de la pila. Cuando lo normal
Mecanismos de desenrollado de pila: uso de registros Dwarf CFI y seguimiento de puntero de cuadro
- falla, el escaneo de la pila puede recuperar un seguimiento de la pila.

Tenga en cuenta que el escaneo de pilas es un mecanismo heurístico impreciso que puede
resultados engañosos, o ninguno en absoluto. Debe usarse solo en emergencias, cuando es normal
el desenrollado falla y, no obstante, es importante tener seguimientos de pila.

El escaneo de la pila es una técnica simple: el desbobinador lee las palabras de la pila y
trata de adivinar cuál de ellos podría ser la dirección de retorno, comprobando para ver si
apunte justo después de las instrucciones ARM o Thumb call. Si es así, la palabra se agrega al
retroceso.

El principal peligro ocurre cuando una llamada a función regresa, dejando su dirección de retorno.
expuestos, y se llama a una nueva función, pero la nueva función no sobrescribe la antigua
Dirección. El resultado de esto es que el backtrace puede contener entradas para funciones
que ya han regresado, por lo que son muy confusos.

Una segunda limitación de esta implementación es que escaneará solo la página (4 KB,
normalmente) que contiene el puntero de la pila inicial. Si los marcos de la pila son grandes, esto
puede resultar en que solo unos pocos (o incluso ninguno) estén presentes en la traza. Además, si tu
tienen mala suerte y tienen un puntero de pila inicial cerca del final de la página que los contiene, el
el escaneo puede perder todos los cuadros interesantes.

De forma predeterminada, el escaneo de pilas está deshabilitado. El caso de uso normal es solicitarlo cuando un
De lo contrario, el seguimiento de la pila sería muy corto. Entonces, para habilitarlo, use
--unw-stack-scan-thresh = número. Esto solicita a Valgrind que intente usar el escaneo de pila para
"extender" las trazas de pila que contienen menos de un número de marcos.

Si se lleva a cabo el escaneo de la pila, solo generará como máximo la cantidad de marcos
especificado por --unw-stack-scan-frames. Normalmente, el escaneo de pilas genera tantos
entradas basura que este valor se establece en un valor bajo (5) de forma predeterminada. En ningún caso
Se cree un seguimiento de pila mayor que el valor especificado por --num-callers.

--error-limit = [defecto: sí]
Cuando está habilitado, Valgrind deja de informar errores después de 10,000,000 en total, o 1,000
diferentes, se han visto. Esto es para evitar que la maquinaria de seguimiento de errores
convirtiéndose en una enorme sobrecarga de rendimiento en programas con muchos errores.

--error-exitcode = [defecto: 0]
Especifica un código de salida alternativo para devolver si Valgrind informó algún error en el
correr. Cuando se establece en el valor predeterminado (cero), el valor de retorno de Valgrind siempre
ser el valor de retorno del proceso que se está simulando. Cuando se establece en un valor distinto de cero,
en su lugar, se devuelve un valor si Valgrind detecta algún error. Esto es útil para usar
Valgrind como parte de un conjunto de pruebas automatizado, ya que facilita la detección de pruebas
casos para los que Valgrind ha informado errores, simplemente inspeccionando los códigos de retorno.

--error-markers = , [defecto: ninguno]
Cuando los errores se generan como texto sin formato (es decir, XML no se utiliza), - marcadores de error instruye a
generar una línea que contenga el begin (final) cadena antes (después) de cada error.

Tales líneas de marcador facilitan la búsqueda de errores y / o la extracción de errores en un
archivo de salida que contiene errores valgrind mezclados con la salida del programa.

Tenga en cuenta que se aceptan marcadores vacíos. Entonces, solo usar un marcador de inicio (o final) es
posible.

--sigill-diagnostics = [defecto: sí]
Activar / desactivar la impresión de diagnósticos de instrucciones ilegales. Habilitado de forma predeterminada, pero
predeterminado a deshabilitado cuando --tranquilo es dado. El valor predeterminado siempre puede ser explícitamente
anulado dando esta opción.

Cuando está habilitado, se imprimirá un mensaje de advertencia, junto con algunos diagnósticos, siempre que
se encuentra una instrucción que Valgrind no puede decodificar o traducir, antes de que
El programa recibe una señal SIGILL. A menudo, una instrucción ilegal indica un error en el
programa o falta de soporte para la instrucción particular en Valgrind. Pero algunos
los programas intentan deliberadamente ejecutar una instrucción que podría faltar y atrapar
la señal SIGILL para detectar características del procesador. El uso de esta bandera hace posible
Evite el resultado de diagnóstico que de otro modo obtendría en tales casos.

--show-below-main = [defecto: No]
De forma predeterminada, los seguimientos de pila para errores no muestran ninguna función que aparezca debajo principal
porque la mayoría de las veces son cosas poco interesantes de la biblioteca de C y / o palabrerías.
Alternativamente, si principal no está presente en el seguimiento de la pila, los seguimientos de la pila no se mostrarán
cualquier función a continuación principal-funciones similares a las de glibc __libc_start_main.
Además, si principal-como funciones están presentes en la traza, se normalizan como
(abajo principal), para que la salida sea más determinista.

Si esta opción está habilitada, todas las entradas de seguimiento de pila se mostrarán y principal-Como
las funciones no se normalizarán.

--fullpath-after = [defecto: don't show fuente caminos]
De forma predeterminada, Valgrind solo muestra los nombres de archivo en los seguimientos de la pila, pero no las rutas completas a
archivos fuente. Cuando se utiliza Valgrind en proyectos grandes donde residen las fuentes
varios directorios diferentes, esto puede ser un inconveniente. --fullpath-después proporciona una
solución flexible a este problema. Cuando esta opción está presente, la ruta a cada
Se muestra el archivo de origen, con la siguiente advertencia importante: si cadena se encuentra en
el camino, luego el camino hasta e incluyendo cadena se omite, de lo contrario se muestra la ruta
sin modificar. Tenga en cuenta que cadena no es necesario que sea un prefijo de la ruta.

Por ejemplo, considere un archivo llamado /home/janedoe/blah/src/foo/bar/xyzzy.c. Especificando
--fullpath-after = / inicio / janedoe / blah / src / hará que Valgrind muestre el nombre como
foo / bar / xyzzy.c.

Dado que no es necesario que la cadena sea un prefijo, --fullpath-after = src / Producirá
la misma salida. Esto es útil cuando la ruta contiene arbitrarios generados por máquina
caracteres. Por ejemplo, la ruta / my / build / dir / C32A1B47 / blah / src / foo / xyzzy puede ser
podado a foo / xyzzy usando --fullpath-after = / blah / src /.

Si simplemente desea ver la ruta completa, especifique una cadena vacía:
--fullpath-after =. Este no es un caso especial, simplemente una consecuencia lógica de la
reglas anteriores.

Finalmente, puedes usar --fullpath-después varias veces. Cualquier aparición causa
Valgrind para cambiar a producir rutas completas y aplicar la regla de filtrado anterior. Cada
ruta producida se compara con todos los --fullpath-después-cadenas especificadas, en el
orden especificada. La primera cadena que coincide hace que la ruta se trunque como
descrito arriba. Si ninguno coincide, se muestra la ruta completa. Esto facilita cortar
prefijos cuando las fuentes se extraen de varios directorios no relacionados.

--extra-debuginfo-path = [defecto: indefinido y no usado]
De forma predeterminada, Valgrind busca en varias rutas conocidas de objetos de depuración, como
/ usr / lib / debug /.

Sin embargo, puede haber escenarios en los que desee colocar objetos de depuración en un
ubicación arbitraria, como almacenamiento externo cuando se ejecuta Valgrind en un dispositivo móvil
con almacenamiento local limitado. Otro ejemplo podría ser una situación en la que no tiene
permiso para instalar paquetes de objetos de depuración en el sistema donde está ejecutando
Valgrind.

En estos escenarios, puede proporcionar una ruta absoluta como un lugar final adicional para
Valgrind para buscar objetos de depuración especificando
--extra-debuginfo-path = / ruta / a / debug / objetos. La ruta dada se antepondrá a la
nombre de ruta absoluta del objeto buscado. Por ejemplo, si Valgrind está buscando
la debuginfo para /w/x/y/zz.so y --extra-debuginfo-path = / a / b / c se especifica, lo hará
busque un objeto de depuración en /a/b/c/w/x/y/zz.so.

Esta bandera solo debe especificarse una vez. Si se especifica varias veces, solo el
se honra la última instancia.

--debuginfo-server = ipaddr: puerto [defecto: indefinido y no usado]
Esta es una característica nueva y experimental introducida en la versión 3.9.0.

En algunos escenarios, puede ser conveniente leer la información de depuración de los objetos almacenados en un
máquina diferente. Con esta bandera, Valgrind consultará un servidor debuginfo que se ejecuta en
ipaddr y escuchando en el puerto, si no puede encontrar el objeto debuginfo en el local
sistema de archivos

El servidor debuginfo debe aceptar conexiones TCP en el puerto del puerto. El servidor debuginfo es
contenido en el archivo fuente auxprogs / valgrind-di-server.c. Solo servirá desde
el directorio en el que se inicia. puerto predeterminado es 1500 tanto en el cliente como en el servidor si
no especificado.

Si Valgrind busca debuginfo para /w/x/y/zz.so utilizando el servidor debuginfo,
eliminará los componentes del nombre de ruta y simplemente solicitará zz.so en el servidor. Que en
turn buscará solo en su directorio de trabajo actual un objeto debuginfo que coincida.

Los datos de debuginfo se transmiten en pequeños fragmentos (8 KB) según lo solicitado por Valgrind.
Cada bloque se comprime utilizando LZO para reducir el tiempo de transmisión. La implementación tiene
se ha ajustado para obtener el mejor rendimiento en un enlace de red 802.11g (WiFi) de una sola etapa.

Tenga en cuenta que comprueba la coincidencia de los objetos primarios con los de depuración, utilizando GNU debuglink CRC
esquema, se realizan incluso cuando se utiliza el servidor debuginfo. Para deshabilitar dicha verificación,
también debe especificar --allow-faltatched-debuginfo = yes.

De forma predeterminada, el sistema de compilación de Valgrind compilará valgrind-di-server para el objetivo
plataforma, que es casi seguro que no es lo que desea. Hasta ahora no hemos podido
Descubra cómo conseguir que automake / autoconf lo cree para la plataforma de compilación. Si quieres
para usarlo, tendrá que recompilarlo a mano usando el comando que se muestra en la parte superior de
auxprogs / valgrind-di-server.c.

--allow-discordante-debuginfo = no | sí [No]
Al leer debuginfo de objetos de debuginfo separados, Valgrind verificará de forma predeterminada
que los objetos main y debuginfo coincidan, utilizando el mecanismo debuglink de GNU. Esta
garantiza que no lee debuginfo de objetos debuginfo obsoletos, y
también asegura que Valgrind no pueda fallar como resultado de desajustes.

Esta verificación se puede anular usando --allow-faltatched-debuginfo = yes. Esto podría ser
útil cuando debuginfo y los objetos principales no se han dividido correctamente. Ser
Sin embargo, tenga cuidado al usar esto: deshabilita todas las comprobaciones de coherencia, y Valgrind
Se ha observado que falla cuando los objetos main y debuginfo no coinciden.

--supressions = [defecto: $ PREFIX / lib / valgrind / default.supp]
Especifica un archivo adicional desde el que leer las descripciones de los errores que se deben suprimir. Puedes
utilice hasta 100 archivos de supresión adicionales.

- supresiones de genes = [defecto: No]
Cuando se establece en si, Valgrind se detendrá después de cada error mostrado e imprimirá la línea:

---- ¿Supresión de impresión? --- [Devolver / N / n / Y / y / C / c] ----

Prensado Jubiladoo N Jubilado or n Jubilado, hace que Valgrind continúe la ejecución sin imprimir un
supresión de este error.

Prensado Y Jubilado or y Jubilado hace que Valgrind escriba una supresión de este error. Usted puede
luego córtelo y péguelo en un archivo de supresión si no desea saber
error en el futuro.

Cuando se establece en all, Valgrind imprimirá una supresión por cada error informado, sin
consultar al usuario.

Esta opción es particularmente útil con programas C ++, ya que imprime el
supresiones con nombres destrozados, según sea necesario.

Tenga en cuenta que las supresiones impresas son lo más específicas posible. Es posible que desee en común
hasta similares, agregando comodines a los nombres de las funciones y usando el nivel de marco
comodines. Las instalaciones de comodines son potentes pero flexibles, y con un poco de
edición cuidadosa, es posible que pueda suprimir toda una familia de errores relacionados con
sólo unas pocas supresiones.

A veces, dos errores diferentes son suprimidos por la misma supresión, en cuyo caso
Valgrind generará la supresión más de una vez, pero solo necesita tener una
copie en su archivo de supresión (pero tener más de uno no causará problemas). También,
el nombre de supresión se da como ; el nombre no
realmente importa, solo se usa con el -v opción que imprime toda la supresión utilizada
Records.

--input-fd = [defecto: 0, entrada estándar]
Cuando usas - supresiones de genes = sí, Valgrind se detendrá para leer la entrada del teclado
de usted cuando ocurre cada error. Por defecto lee de la entrada estándar (stdin),
lo cual es problemático para los programas que cierran stdin. Esta opción le permite especificar
un descriptor de archivo alternativo desde el que leer la entrada.

--dsymutil = no | sí [sí]
Esta opción solo es relevante cuando se ejecuta Valgrind en Mac OS X.

Mac OS X utiliza un esquema de enlace de información de depuración diferida (debuginfo). Cuando objeto
Los archivos que contienen debuginfo están vinculados a un .dylib o un ejecutable, debuginfo es
no copiado en el archivo final. En su lugar, debuginfo debe vincularse manualmente mediante
ejecutando dsymutil, una utilidad proporcionada por el sistema, en el ejecutable o .dylib. los
La información de depuración combinada resultante se coloca en un directorio junto al ejecutable o
.dylib, pero con la extensión .dSYM.

En nuestro --dsymutil = no, Valgrind detectará los casos en los que el directorio .dSYM sea
falta, o está presente pero no parece coincidir con el ejecutable asociado o
.dylib, probablemente porque no está actualizado. En estos casos, Valgrind imprimirá un
mensaje de advertencia, pero no realice ninguna otra acción.

En nuestro --dsymutil = sí, Valgrind, en tales casos, ejecutará automáticamente dsymutil como
necesario para actualizar la información de depuración. A todos los efectos prácticos, si siempre
use --dsymutil = sí, entonces nunca hay necesidad de ejecutar dsymutil manualmente o como parte
del sistema de compilación de sus aplicaciones, ya que Valgrind lo ejecutará según sea necesario.

Valgrind no intentará ejecutar dsymutil en ningún ejecutable o biblioteca en / usr /,
/bin/ , / sbin /, / Opt /, / sw /, / System /, / Library / o / Applications / ya que dsymutil
siempre falla en tales situaciones. Falla tanto porque la debuginfo para tal
Los componentes del sistema preinstalados no están disponibles en ningún lugar, y también porque
requieren privilegios de escritura en esos directorios.

Tenga cuidado al usar --dsymutil = sí, ya que causará .dSYM preexistente
directorios para ser eliminados y recreados silenciosamente. También tenga en cuenta que dsymutil es bastante
lento, a veces excesivamente.

--max-stackframe = [defecto: 2000000]
El tamaño máximo de un marco de pila. Si el puntero de la pila se mueve más de esta cantidad
entonces Valgrind asumirá que el programa está cambiando a una pila diferente.

Es posible que deba utilizar esta opción si su programa tiene matrices grandes asignadas en la pila.
Valgrind realiza un seguimiento del puntero de pila de su programa. Si cambia en más del
cantidad de umbral, Valgrind asume que su programa está cambiando a una pila diferente, y
Memcheck se comporta de manera diferente a como lo haría para un cambio de puntero de pila más pequeño que el
umbral. Por lo general, esta heurística funciona bien. Sin embargo, si su programa asigna grandes
estructuras en la pila, esta heurística será engañada, y Memcheck posteriormente
reportar un gran número de accesos de pila no válidos. Esta opción le permite cambiar el
umbral a un valor diferente.

Solo debe considerar el uso de esta opción si la salida de depuración de Valgrind lo dirige a
hazlo. En ese caso, le indicará el nuevo umbral que debe especificar.

En general, asignar estructuras grandes en la pila es una mala idea, porque puede
quedarse sin espacio de pila fácilmente, especialmente en sistemas con memoria limitada o que
espera admitir una gran cantidad de subprocesos, cada uno con una pequeña pila, y también porque
la verificación de errores realizada por Memcheck es más efectiva para los datos asignados al montón
que para los datos asignados a la pila. Si tiene que utilizar esta opción, es posible que desee
considere reescribir su código para asignarlo en el montón en lugar de en la pila.

--main-stacksize = [defecto: use corriente 'ulimit' valor]
Especifica el tamaño de la pila del hilo principal.

Para simplificar su gestión de memoria, Valgrind reserva todo el espacio necesario para la
pila de subprocesos al inicio. Eso significa que necesita saber el tamaño de pila requerido en
puesta en marcha.

De forma predeterminada, Valgrind usa el valor actual "ulimit" para el tamaño de la pila, o 16 MB,
el que sea más bajo. En muchos casos, esto da un tamaño de pila en el rango de 8 a 16 MB,
que casi nunca se desborda para la mayoría de las aplicaciones.

Si necesita un tamaño total de pila mayor, use --main-stackize para especificarlo. Solo configúralo
tan alto como necesite, ya que reserva mucho más espacio del que necesita (es decir, cientos
de megabytes más de lo que necesita) restringe los asignadores de memoria de Valgrind y puede
reducir la cantidad total de memoria que Valgrind puede usar. Esto es solo realmente de
importancia en máquinas de 32 bits.

En Linux, puede solicitar una pila de hasta 2 GB. Valgrind se detendrá con un
mensaje de diagnóstico si no se puede asignar la pila.

--main-stackize solo afecta el tamaño de la pila para el hilo inicial del programa. Tiene
no influye en el tamaño de las pilas de hilos, ya que Valgrind no las asigna.

Puede que necesite usar ambos --main-stackize y --max-stackframe juntos. Está
importante entender que --main-stackize establece el tamaño máximo total de la pila,
mientras que --max-stackframe especifica el tamaño más grande de cualquier marco de pila. Vas a
tengo que resolver el --main-stackize valor para usted (por lo general, si su
aplicaciones segfaults). Pero Valgrind te dirá lo necesario --max-stackframe XNUMX participantes
si necesario.

Como se discute más adelante en la descripción de --max-stackframe, un requisito para una gran
stack es una señal de posibles problemas de portabilidad. Es mejor que coloque todos
grandes datos en la memoria asignada al montón.

--max-hilos = [defecto: 500]
De forma predeterminada, Valgrind puede manejar hasta 500 subprocesos. Ocasionalmente, ese número es demasiado
pequeña. Utilice esta opción para proporcionar un límite diferente. Por ejemplo, --max-threads = 3000.

MALLOC () - RELACIONADO OPCIONES

Para las herramientas que utilizan su propia versión de malloc (por ejemplo, Memcheck, Massif, Helgrind, DRD),
Se aplican las siguientes opciones.

--alineamiento = [defecto: 8 or 16, dependiendo on los plataforma]
Por defecto Valgrind's malloc, reasignar, etc., devuelve un bloque cuya dirección inicial es
8 bytes alineados o 16 bytes alineados (el valor depende de la plataforma y coincide con el
plataforma predeterminada). Esta opción le permite especificar una alineación diferente. los
El valor proporcionado debe ser mayor o igual que el predeterminado, menor o igual que
4096, y debe ser una potencia de dos.

--redzone-size = [defecto: depende on los herramienta]
De Valgrind malloc, reasignar, etc, agregue bloques de relleno antes y después de cada bloque de montón
asignado por el programa que se está ejecutando. Estos bloques de relleno se denominan zonas redondas. los
El valor predeterminado para el tamaño de la zona roja depende de la herramienta. Por ejemplo, Memcheck agrega y
protege un mínimo de 16 bytes antes y después de cada bloque asignado por el cliente.
Esto le permite detectar insuficiencias o desbordamientos de bloques de hasta 16 bytes.

Aumentar el tamaño de la zona roja permite detectar desbordamientos de distancias mayores,
pero aumenta la cantidad de memoria utilizada por Valgrind. Disminuir el tamaño de la zona roja
reducir la memoria que necesita Valgrind, pero también reduce las posibilidades de detectar
over / underruns, por lo que no se recomienda.

POCO COMÚN OPCIONES

Estas opciones se aplican a todas las herramientas, ya que afectan a ciertos trabajos oscuros del Valgrind.
centro. La mayoría de las personas no necesitarán usarlos.

--smc-check = [defecto: todo-no-archivo for x86 / amd64 / s390x,
montón for other arcos]
Esta opción controla la detección de Valgrind de código que se modifica automáticamente. Si no hay cheque
hecho, cuando un programa ejecuta algún código, luego lo sobrescribe con un nuevo código, y
ejecuta el nuevo código, Valgrind continuará ejecutando las traducciones que hizo para
el código antiguo. Esto probablemente dará lugar a un comportamiento incorrecto y / o bloqueos.

Para arquitecturas "modernas", cualquier cosa que no sea x86, amd64 o s390x, el valor predeterminado
is montón. Esto se debe a que un programa correcto debe tomar una acción explícita para restablecer
Coherencia de caché DI después de la modificación del código. Valgrind observa y honra tales
acciones, con el resultado de que el código de modificación automática se maneja de forma transparente con cero
costo adicional.

Para x86, amd64 y s390x, no es necesario que el programa notifique al hardware
requiere sincronización de coherencia DI. Por lo tanto, el valor predeterminado es todo-no-archivo, que cubre el
caso normal de generar código en un área mmap anónima (sin respaldo de archivo).

Los significados de los cuatro ajustes disponibles son los siguientes. Sin detectar (ninguna),
detectar código auto-modificable en la pila (que es usado por GCC para implementar anidado
funciones) (montón), detecta código de modificación automática en todas partes (all) y detectar
código auto modificable en todas partes excepto en asignaciones respaldadas por archivos (todo-no-archivo).

Corriendo con all Ralentizará a Valgrind notablemente. Corriendo con ninguna rara vez
acelerar las cosas, ya que muy poco código se genera dinámicamente en la mayoría de los programas.
El VALGRIND_DISCARD_TRANSLACIONES la solicitud del cliente es una alternativa a --smc-check = todo
y --smc-check = todo-no-archivo que requiere más esfuerzo del programador pero permite a Valgrind
para ejecutar su programa más rápido, indicándole con precisión cuándo deben realizarse las traducciones
rehecho.

--smc-check = todo-no-archivo proporciona una versión más barata pero más limitada de
--smc-check = todo. Agrega cheques a cualquier traducción que no se origine en
Asignaciones de memoria respaldadas por archivos. Aplicaciones típicas que generan código, por ejemplo, JIT
en los navegadores web, genera código en áreas mmaped anónimas, mientras que el código "fijo"
del navegador siempre vive en asignaciones respaldadas por archivos. --smc-check = todo-no-archivo toma
ventaja de esta observación, limitando la sobrecarga de verificación al código que es
Es probable que se genere JIT.

--read-inline-info = [defecto: ver abajo]
Cuando está habilitado, Valgrind leerá información sobre llamadas a funciones en línea desde DWARF3
información de depuración. Esto ralentiza el inicio de Valgrind y hace que utilice más memoria (normalmente para
cada pieza de código en línea, 6 palabras y espacio para el nombre de la función), pero resulta
en stacktraces más descriptivos. Para la versión 3.10.0, esta funcionalidad está habilitada
de forma predeterminada solo para destinos Linux, Android y Solaris y solo para las herramientas
Memcheck, Helgrind y DRD. Aquí hay un ejemplo de algunos trazos de pila con
--read-inline-info = no:

== 15380 == El salto o movimiento condicional depende de los valores no inicializados
== 15380 == en 0x80484EA: principal (inlinfo.c: 6)
== 15380 ==
== 15380 == El salto o movimiento condicional depende de los valores no inicializados
== 15380 == en 0x8048550: fun_noninline (inlinfo.c: 6)
== 15380 == por 0x804850E: main (inlinfo.c: 34)
== 15380 ==
== 15380 == El salto o movimiento condicional depende de los valores no inicializados
== 15380 == en 0x8048520: main (inlinfo.c: 6)

Y aquí están los mismos errores con --read-inline-info = sí:

== 15377 == El salto o movimiento condicional depende de los valores no inicializados
== 15377 == en 0x80484EA: fun_d (inlinfo.c: 6)
== 15377 == por 0x80484EA: fun_c (inlinfo.c: 14)
== 15377 == por 0x80484EA: fun_b (inlinfo.c: 20)
== 15377 == por 0x80484EA: fun_a (inlinfo.c: 26)
== 15377 == por 0x80484EA: main (inlinfo.c: 33)
== 15377 ==
== 15377 == El salto o movimiento condicional depende de los valores no inicializados
== 15377 == en 0x8048550: fun_d (inlinfo.c: 6)
== 15377 == por 0x8048550: fun_noninline (inlinfo.c: 41)
== 15377 == por 0x804850E: main (inlinfo.c: 34)
== 15377 ==
== 15377 == El salto o movimiento condicional depende de los valores no inicializados
== 15377 == en 0x8048520: fun_d (inlinfo.c: 6)
== 15377 == por 0x8048520: main (inlinfo.c: 35)

--read-var-info = [defecto: No]
Cuando está habilitado, Valgrind leerá información sobre tipos de variables y ubicaciones de
Información de depuración de DWARF3. Esto ralentiza significativamente el inicio de Valgrind y hace que utilice
significativamente más memoria, pero para las herramientas que pueden aprovecharla (Memcheck,
Helgrind, DRD) puede resultar en mensajes de error más precisos. Por ejemplo, aquí están
algunos errores estándar emitidos por Memcheck:

== 15363 == Byte (s) sin inicializar encontrados durante la solicitud de verificación del cliente
== 15363 == en 0x80484A9: croar (varinfo1.c: 28)
== 15363 == por 0x8048544: main (varinfo1.c: 55)
== 15363 == La dirección 0x80497f7 tiene 7 bytes dentro del símbolo de datos "global_i2"
== 15363 ==
== 15363 == Byte (s) sin inicializar encontrados durante la solicitud de verificación del cliente
== 15363 == en 0x80484A9: croar (varinfo1.c: 28)
== 15363 == por 0x8048550: main (varinfo1.c: 56)
== 15363 == La dirección 0xbea0d0cc está en la pila del hilo 1
== 15363 == en el marco # 1, creado por main (varinfo1.c: 45)

Y aquí están los mismos errores con --read-var-info = sí:

== 15370 == Byte (s) sin inicializar encontrados durante la solicitud de verificación del cliente
== 15370 == en 0x80484A9: croar (varinfo1.c: 28)
== 15370 == por 0x8048544: main (varinfo1.c: 55)
== 15370 == La ubicación 0x80497f7 es 0 bytes dentro de global_i2 [7],
== 15370 == una variable global declarada en varinfo1.c: 41
== 15370 ==
== 15370 == Byte (s) sin inicializar encontrados durante la solicitud de verificación del cliente
== 15370 == en 0x80484A9: croar (varinfo1.c: 28)
== 15370 == por 0x8048550: main (varinfo1.c: 56)
== 15370 == La ubicación 0xbeb4a0cc es 0 bytes dentro de la var local "local"
== 15370 == declarado en varinfo1.c: 46, en el marco # 1 del hilo 1

--vgdb-poll = [defecto: 5000]
Como parte de su ciclo principal, el programador de Valgrind sondeará para verificar si alguna actividad
(como un comando externo o alguna entrada de un gdb) tiene que ser manejado por gdbserver.
Esta encuesta de actividad se realizará después de haber ejecutado el número dado de bloques básicos (o
un poco más que el número dado de bloques básicos). Esta encuesta es bastante barata, por lo que
El valor predeterminado se establece relativamente bajo. Puede reducir aún más este valor si vgdb
no puede usar la llamada al sistema ptrace para interrumpir Valgrind si todos los hilos están
tiempo) bloqueado en una llamada al sistema.

--vgdb-shadow-registers = no | sí [defecto: No]
Cuando se activa, gdbserver expondrá los registros de sombra de Valgrind a GDB. Con este,
el valor de los registros de sombra de Valgrind se puede examinar o cambiar usando GDB.
La exposición de registros de sombra solo funciona con GDB versión 7.1 o posterior.

--vgdb-prefix = [defecto: / tmp / vgdb-pipe]
Para comunicarse con gdb / vgdb, Valgrind gdbserver crea 3 archivos (2 llamados FIFO
y un archivo de memoria compartida mmap). La opción de prefijo controla el directorio y el prefijo
para la creación de estos archivos.

--run-libc-freeres = [defecto: sí]
Esta opción solo es relevante cuando se ejecuta Valgrind en Linux.

La biblioteca GNU C (libc.so), que utilizan todos los programas, puede asignar memoria para
sus propios usos. Por lo general, no se molesta en liberar esa memoria cuando finaliza el programa.
No tendría sentido, ya que el kernel de Linux recupera todos los recursos del proceso cuando un
el proceso sale de todos modos, por lo que solo ralentizaría las cosas.

Los autores de glibc se dieron cuenta de que este comportamiento provoca que los verificadores de fugas, como Valgrind,
para informar falsamente de fugas en glibc, cuando se realiza una verificación de fugas en la salida. Para evitar
esto, proporcionaron una rutina llamada __libc_freeres específicamente para hacer glibc release
toda la memoria que ha asignado. Por tanto, Memcheck intenta ejecutar __libc_freeres a la salida.

Desafortunadamente, en algunas versiones muy antiguas de glibc, __libc_freeres es suficientemente
buggy para causar fallas de segmentación. Esto fue particularmente notable en Red Hat 7.1.
Por lo tanto, esta opción se proporciona para inhibir la ejecución de __libc_freeres. Si su
programa parece funcionar bien en Valgrind, pero segfaults al salir, puede encontrar que
--run-libc-freeres = no corrige eso, aunque a costa de posiblemente informar falsamente
fugas de espacio en libc.so.

--sim-hints = hint1, hint2, ...
Pase varias sugerencias a Valgrind que modifiquen ligeramente el comportamiento simulado en
formas no estándar o peligrosas, posiblemente para ayudar a la simulación de características extrañas. Por
por defecto, no hay sugerencias habilitadas. ¡Úselo con precaución! Las sugerencias actualmente conocidas son:

· laxos-ioctls: Sea muy laxo con el manejo de ioctl; la única suposición es que el tamaño
es correcto. No requiere que se inicialice todo el búfer al escribir.
Sin esto, el uso de algunos controladores de dispositivo con una gran cantidad de ioctl extrañas
Los comandos se vuelven muy tediosos.

· compatible con fusibles: Habilite el manejo especial para ciertas llamadas al sistema que pueden bloquear
en un sistema de archivos FUSE. Esto puede ser necesario cuando se ejecuta Valgrind en un
Programa de múltiples subprocesos que utiliza un subproceso para administrar un sistema de archivos FUSE y
otro hilo para acceder a ese sistema de archivos.

· habilitar-exterior: Habilite alguna magia especial necesaria cuando el programa que se está ejecutando
sí mismo Valgrind.

· sin prefijo interno: Deshabilitar la impresión de un prefijo > delante de cada stdout o stderr
línea de salida en un Valgrind interior que está siendo ejecutado por un Valgrind exterior. Esto es útil
al ejecutar pruebas de regresión de Valgrind en una configuración externa / interna. Tenga en cuenta que el
prefijo > siempre se imprimirá delante de las líneas internas de registro de depuración.

· no-nptl-pthread-stackcache: Esta sugerencia solo es relevante cuando se ejecuta Valgrind en
Linux.

La biblioteca GNU glibc pthread (libpthread.so), que utilizan los programas pthread,
mantiene un caché de pilas de pthread. Cuando termina un pthread, la memoria utilizada
para la pila pthread y algunas estructuras de datos relacionadas con el almacenamiento local de subprocesos no son
siempre lanzado directamente. Esta memoria se guarda en una caché (hasta cierto tamaño),
y se reutiliza si se inicia un nuevo hilo.

Este caché hace que la herramienta helgrind informe alguna condición de carrera falsa positiva
errores en esta memoria caché, ya que helgrind no comprende la glibc interna
primitivas de sincronización de caché. Entonces, al usar helgrind, deshabilitar el caché
ayuda a evitar condiciones de carrera de falsos positivos, en particular cuando se utiliza hilo
variables de almacenamiento local (por ejemplo, variables que utilizan el __hilo Calificatorio).

Al usar la herramienta Memcheck, deshabilitar la caché asegura que la memoria utilizada por glibc
para manejar las variables __thread se libera directamente cuando termina un hilo.

Nota: Valgrind deshabilita la caché usando algunos conocimientos internos de la pila glibc
implementación de caché y examinando la información de depuración del pthread
Biblioteca. Por lo tanto, esta técnica es algo frágil y podría no funcionar para todos los glibc.
versiones. Esto se ha probado con éxito con varias versiones de glibc (p. Ej.
2.11, 2.16, 2.18) en varias plataformas.

· puertas laxas: (Solo Solaris) Sea muy laxo en el manejo de llamadas al sistema de la puerta
descriptores de archivos de puertas no reconocidos. No requiere que el búfer completo esté
inicializado al escribir. Sin esto, los programas que usan puerta libre(3LIB) funcionalidad
con semántica completamente propietaria puede reportar un gran número de falsos positivos.

--fair-sched = [defecto: No]
El --justo programado La opción controla el mecanismo de bloqueo utilizado por Valgrind para serializar
ejecución del hilo. El mecanismo de bloqueo controla la forma en que se programan los hilos,
y los diferentes escenarios dan diferentes compensaciones entre equidad y desempeño. Para
más detalles sobre el esquema de serialización de subprocesos de Valgrind y su impacto en
rendimiento y programación de subprocesos, consulte Programación y rendimiento de subprocesos múltiples.

· El valor --fair-sched = sí activa un programador justo. En resumen, si varios
los subprocesos están listos para ejecutarse, los subprocesos se programarán en forma rotatoria.
Este mecanismo no está disponible en todas las plataformas o versiones de Linux. Que no
disponible, usando --fair-sched = sí hará que Valgrind termine con un error.

Puede encontrar que esta configuración mejora la capacidad de respuesta general si está ejecutando un
programa interactivo multiproceso, por ejemplo, un navegador web, en Valgrind.

· El valor --fair-sched = probar activa la programación justa si está disponible en la plataforma.
De lo contrario, volverá automáticamente a --fair-sched = no.

· El valor --fair-sched = no activa un programador que no garantiza la equidad
entre subprocesos listos para ejecutarse, pero que en general ofrece el mayor rendimiento.

--kernel-variant = variant1, variant2, ...
Manejar llamadas al sistema e ioctls que surgen de variantes menores del kernel predeterminado para
esta plataforma. Esto es útil para ejecutar en kernels pirateados o con módulos de kernel
que admiten ioctls no estándar, por ejemplo. Úselo con precaución. Si no lo haces
Si comprende lo que hace esta opción, es casi seguro que no la necesite. En la actualidad
las variantes conocidas son:

· bproc: apoyen el sistema_broc llamada al sistema en x86. Esto es para ejecutar en BProc,
que es una variante menor de Linux estándar que a veces se usa para construir
racimos

· Android-sin-hw-tls: algunas versiones del emulador de Android para ARM no proporcionan
Registro de hardware TLS (estado local de subprocesos) y Valgrind se bloquea al inicio. Usar
esta variante para seleccionar el soporte de software para TLS.

· android-gpu-sgx5xx: use esto para admitir el manejo de ioctls propietarios para el
Serie de GPU PowerVR SGX 5XX en dispositivos Android. Si no selecciona esto, no
causar problemas de estabilidad, pero puede hacer que Memcheck informe errores falsos después de la
El programa realiza ioctls específicos de GPU.

· android-gpu-adreno3xx: de manera similar, use esto para admitir el manejo de propietarios
ioctls para la serie de GPU Qualcomm Adreno 3XX en dispositivos Android.

--merge-recursive-frames = [defecto: 0]
Algunos algoritmos recursivos, por ejemplo, implementaciones de árbol binario balanceado, crean
muchos seguimientos de pila diferentes, cada uno de los cuales contiene ciclos de llamadas. Un ciclo se define como
dos valores de contador de programa idénticos separados por cero o más otros contadores de programa
valores. Valgrind puede entonces usar mucha memoria para almacenar todos estos rastros de pila. Este es
un mal uso de la memoria teniendo en cuenta que tales rastros de pila contienen repetidos y poco interesantes
llamadas recursivas en lugar de información más interesante, como la función que tiene
inició la llamada recursiva.

La opción --merge-recursive-frames = instruye a Valgrind para detectar y fusionar
ciclos de llamadas recursivas que tienen un tamaño de hasta marcos. Cuando tal ciclo es
detectado, Valgrind registra el ciclo en el seguimiento de la pila como un contador de programa único.

El valor 0 (el predeterminado) no provoca la fusión de llamadas recursivas. Un valor de 1 provocará
apilar seguimientos de algoritmos recursivos simples (por ejemplo, una implementación factorial)
colapsar. Por lo general, se necesitará un valor de 2 para contraer los rastros de pila producidos
mediante algoritmos recursivos como árboles binarios, ordenación rápida, etc. Los valores más altos pueden ser
necesario para algoritmos recursivos más complejos.

Nota: las llamadas recursivas se detectan mediante el análisis de los valores del contador del programa. No son
detectado mirando los nombres de las funciones.

--num-transtab-sectores = [defecto: 6 for Android plataformas, 16 for all otros]
Valgrind traduce e instrumenta el código de máquina de su programa en pequeños fragmentos
(bloques básicos). Las traducciones se almacenan en una caché de traducción que se divide
en una serie de secciones (sectores). Si la caché está llena, el sector que contiene el
las traducciones más antiguas se vacían y se reutilizan. Si estas viejas traducciones son necesarias nuevamente,
Valgrind debe volver a traducir y volver a instrumentar el código de máquina correspondiente, que es
costoso. Si el conjunto de trabajo de "instrucciones ejecutadas" de un programa es grande, aumentar
el número de sectores puede mejorar el desempeño al reducir el número de
re-traducciones necesarias. Los sectores se asignan bajo demanda. Una vez asignado, un sector puede
nunca se libera y ocupa un espacio considerable, dependiendo de la herramienta y el valor
of --avg-transtab-tamaño de entrada (alrededor de 40 MB por sector para Memcheck). Usa la opción
--stats = sí para obtener información precisa sobre la memoria utilizada por un sector y la
asignación y reciclaje de sectores.

--avg-transtab-entry-size = [defecto: 0, sentido use del IRS previsto defecto]
Tamaño medio del bloque básico traducido. Este tamaño medio se utiliza para dimensionar el
tamaño de un sector. Cada herramienta proporciona un valor predeterminado que se utilizará. Si este valor predeterminado
es demasiado pequeño, los sectores de traducción se llenarán demasiado rápido. Si este predeterminado
El valor es demasiado grande, una parte importante de la memoria del sector de traducción no se utilizará.
Tenga en cuenta que el tamaño medio de la traducción de un bloque básico depende de la herramienta y puede
dependen de las opciones de herramientas. Por ejemplo, la opción de memcheck --track-origins = sí aumentos
el tamaño de las traducciones de bloques básicos. Usar --avg-transtab-tamaño de entrada para sintonizar el
tamaño de los sectores, ya sea para ganar memoria o para evitar demasiadas retraducciones.

--aspace-minaddr = [defecto: depende on los plataforma]
Para evitar posibles conflictos con algunas bibliotecas del sistema, Valgrind no utiliza la
espacio de direcciones a continuación --aspace-minaddr valor, manteniéndolo reservado en caso de que una biblioteca
solicita específicamente memoria en esta región. Entonces, se adivina algún valor "pesimista"
por Valgrind dependiendo de la plataforma. En Linux, de forma predeterminada, Valgrind evita usar el
primeros 64 MB, incluso si normalmente no hay ningún conflicto en esta zona completa. Puedes usar
la opción --aspace-minaddr para que su aplicación hambrienta de memoria se beneficie de
más de esta memoria inferior. Por otro lado, si se encuentra con un conflicto, aumentar
El valor aspace-minaddr podría resolverlo. Los conflictos se manifestarán típicamente con
Fallos de mmap en el rango bajo del espacio de direcciones. La dirección proporcionada debe ser página
alineado y debe ser igual o mayor a 0x1000 (4 KB). Para encontrar el valor predeterminado en su
plataforma, haga algo como valgrind -d -d fecha 2> & 1 | grep -i minaddr. Valores
Se sabe que los valores inferiores a 0x10000 (64 KB) crean problemas en algunas distribuciones.

--valgrind-stacksize = [defecto: 1 MB]
Para cada hilo, Valgrind necesita su propia pila 'privada'. El tamaño predeterminado para estos
las pilas está dimensionada en gran medida, por lo que debería ser suficiente en la mayoría de los casos. En caso de
el tamaño es demasiado pequeño, Valgrind fallará. Antes de segfaultar, una advertencia podría ser
producido por Valgrind al acercarse al límite.

Usa la opción --valgrind-tamaño de pila si se produce una advertencia de este tipo (poco probable), o
Valgrind muere debido a una violación de la segmentación. Tales violaciones de segmentación han sido
visto cuando se demandan grandes símbolos de C ++.

Si su aplicación utiliza muchos subprocesos y necesita mucha memoria, puede obtener algunos
memoria reduciendo el tamaño de estas pilas de Valgrind usando la opción
--valgrind-tamaño de pila.

--show-emwarns = [defecto: No]
Cuando está habilitado, Valgrind emitirá advertencias sobre su emulación de CPU en ciertos casos.
Por lo general, estos no son interesantes.

--require-text-symbol =: sonamepatt: fnnamepatt
Cuando un objeto compartido cuyo soname coincide sonamepatt se carga en el proceso,
examinar todos los símbolos de texto que exporta. Si ninguno de esos coincide fnnamepatt, imprime un
mensaje de error y abandone la ejecución. Esto permite asegurarse de que la ejecución
no continuar a menos que un objeto compartido determinado contenga un nombre de función en particular.

Ambos sonamepatt y fnnamepatt se puede escribir usando el habitual ? y * comodines. Para
ejemplo: ": * libc.so *: foo? bar". Puede utilizar caracteres que no sean dos puntos para separar
los dos patrones. Solo es importante que el primer carácter y el separador
el personaje es el mismo. Por ejemplo, el ejemplo anterior también podría escribirse
"Q * libc.so * Qfoo? Bar". Múltiple
--requerir-texto-símbolo Se permiten banderas, en cuyo caso los objetos compartidos que se cargan
en el proceso se compararán con todos ellos.

El propósito de esto es respaldar el uso confiable de bibliotecas marcadas. Por ejemplo,
supongamos que tenemos una versión de GCC libgomp.so que ha sido marcado con
anotaciones para apoyar Helgrind. Es demasiado fácil y confuso cargar el error,
sin anotar libgomp.so en la aplicación. Entonces la idea es: agregue un símbolo de texto en el
biblioteca marcada, por ejemplo anotado_para_helgrind_3_6, y luego dar la bandera
--require-text-symbol =: * libgomp * así que *: annotated_for_helgrind_3_6 para que cuando libgomp.so
está cargado, Valgrind escanea su tabla de símbolos, y si el símbolo no está presente, la ejecución es
abortado, en lugar de continuar silenciosamente con la biblioteca sin marcar. Tenga en cuenta que usted
Debería poner toda la bandera entre comillas para evitar que las conchas se expandan hacia arriba. * y ?
comodines.

--soname-sinónimos = syn1 = patrón1, syn2 = patrón2, ...
Cuando se carga una biblioteca compartida, Valgrind busca funciones en la biblioteca que
debe ser reemplazado o envuelto. Por ejemplo, Memcheck reemplaza todos los relacionados con malloc
funciones (malloc, free, calloc, ...) con sus propias versiones. Tales reemplazos son
hecho de forma predeterminada solo en bibliotecas compartidas cuyo soname coincide con un soname predefinido
patrón (p. ej. libc.so * en linux). De forma predeterminada, no se realiza ningún reemplazo para un
biblioteca vinculada o para bibliotecas alternativas como tcmalloc. En algunos casos, el
los reemplazos permiten --soname-sinónimos para especificar un patrón de sinónimo adicional, dando
flexibilidad en el reemplazo.

Actualmente, esta flexibilidad solo está permitida para las funciones relacionadas con malloc, usando
el sinónimo somalloc. Este sinónimo se puede utilizar para todas las herramientas que realizan un reemplazo estándar.
de funciones relacionadas con malloc (por ejemplo, memcheck, massif, drd, helgrind, exp-dhat,
exp-sgcheck).

· Biblioteca alternativa de malloc: para reemplazar las funciones relacionadas con malloc en una alternativa
biblioteca con soname mymalloclib.so, da la opción
--soname-sinónimos = somalloc = mymalloclib.so. Se puede utilizar un patrón para hacer coincidir varios
bibliotecas sonames. Por ejemplo, --soname-sinónimos = somalloc = * tcmalloc * coincidirá
el soname de todas las variantes de la biblioteca tcmalloc (nativa, depurada, perfilada, ...
variantes tcmalloc).

Nota: el nombre de una biblioteca compartida de elfos se puede recuperar usando el archivo readelf
utilidad.

· Los reemplazos en una biblioteca vinculada estáticamente se realizan mediante el NINGUNO patrón.
Por ejemplo, si enlaza con libtcmalloc.a, Memcheck funcionará correctamente cuando
dar la opción --soname-sinónimos = somalloc = NINGUNO. Tenga en cuenta que un patrón NINGUNO
coincidir con el ejecutable principal y cualquier biblioteca compartida que no tenga soname.

· Para ejecutar una compilación de Firefox "predeterminada" para Linux, en la que JEMalloc está vinculado al
ejecutable principal, use --soname-sinónimos = somalloc = NINGUNO.

DEPURACIÓN VALGRIND OPCIONES

También hay algunas opciones para depurar el propio Valgrind. No deberías necesitar usarlos
en el curso normal de las cosas. Si desea ver la lista, utilice el --ayuda-depuración .

MEMCHEQUE OPCIONES

--leak-check = [defecto: resumen]
Cuando está habilitado, busca pérdidas de memoria cuando finaliza el programa cliente. Si se establece en
resumen, dice cuántas fugas ocurrieron. Si se establece en ser completados or si, cada fuga individual
se mostrará en detalle y / o se contará como un error, según lo especificado por las opciones
- mostrar-tipos-de-fugas y --errores-por-tipos-de-fugas.

--leak-resolution = [defecto: elevado]
Al realizar la verificación de fugas, determina qué tan dispuesto está Memcheck a considerar diferentes
las trazas de retroceso sean las mismas con el propósito de fusionar múltiples fugas en una sola
informe de fugas. Cuando se establece en low, solo las dos primeras entradas deben coincidir. Cuando con, las cuatro
las entradas deben coincidir. Cuando high, todas las entradas deben coincidir.

Para la depuración de fugas graves, probablemente desee utilizar --leak-resolution = alto juntos
con --num-callers = 40 o un número tan grande.

Tenga en cuenta que --resolución de fugas la configuración no afecta la capacidad de Memcheck para encontrar
fugas. Solo cambia la forma en que se presentan los resultados.

--show-fuga-tipos = [defecto: definido, posible]
Especifica los tipos de fugas que se mostrarán en un ser completados búsqueda de fugas, de una de las siguientes formas:

· Una lista separada por comas de uno o más de definido indirecto posible accesible.

· all para especificar el conjunto completo (todo tipo de fugas). Es equivalente a
--show-fuga-tipos = definido, indirecto, posible, alcanzable.

· ninguna para el conjunto vacío.

--errores-por-tipos-de-fugas = [defecto: definido, posible]
Especifica los tipos de fugas para contar como errores en un ser completados búsqueda de fugas. los is
especificado de manera similar a - mostrar-tipos-de-fugas

--leak-check-heuristics = [defecto: todos]
Especifica el conjunto de heurísticas de verificación de fugas que se utilizarán durante las búsquedas de fugas. los
control heurístico qué punteros interiores a un bloque hacen que se considere como
accesible. El conjunto heurístico se especifica de una de las siguientes formas:

· Una lista separada por comas de uno o más de cadena estándar longitud64 nueva matriz
herencia múltiple.

· all para activar el conjunto completo de heurísticas. Es equivalente a
--leak-check-heuristics = stdstring, length64, newarray, multipleinheritance.

· ninguna para el conjunto vacío.

Tenga en cuenta que estas heurísticas dependen del diseño de los objetos producidos por el
Compilador de C ++. Se han probado con algunas versiones de gcc (por ejemplo, 4.4 y 4.7). Ellos
puede que no funcione correctamente con otros compiladores de C ++.

--show-alcanzable = , --show-posiblemente-perdido =
Estas opciones proporcionan una forma alternativa de especificar los tipos de fugas que se mostrarán:

· --show-alcanzable = no --show-possible-lost = sí es equivalente a
--show-fuga-tipos = definido, posible.

· --show-alcanzable = no --show-possible-lost = no es equivalente a
--show-fuga-tipos = definido.

· --show-alcanzable = sí es equivalente a --show-fuga-tipos = todos.

Tenga en cuenta que --show-possible-lost = no no tiene efecto si --show-alcanzable = sí está especificado.

--undef-value-errors = [defecto: sí]
Controla si Memcheck informa usos de errores de valor indefinido. Establezca esto en no if
no desea ver errores de valor indefinido. También tiene el efecto secundario de exceso de velocidad.
Memcheck un poco.

--track-origins = [defecto: No]
Controla si Memcheck rastrea el origen de los valores no inicializados. Por defecto,
no lo hace, lo que significa que, aunque puede decirle que un valor no inicializado es
se utiliza de forma peligrosa, no puede decirle de dónde vino el valor no inicializado
de. Esto a menudo hace que sea difícil rastrear la raíz del problema.

Cuando se establece en si, Memcheck realiza un seguimiento de los orígenes de todos los valores no inicializados.
Luego, cuando se informa un error de valor no inicializado, Memcheck intentará mostrar el
origen del valor. Un origen puede ser uno de los siguientes cuatro lugares: un bloque de pila,
una asignación de pila, una solicitud de cliente u otras fuentes diversas (por ejemplo, una llamada a
freno).

Para valores no inicializados que se originan en un bloque de pila, Memcheck muestra dónde está el bloque
fue asignado. Para valores no inicializados que se originan en una asignación de pila, Memcheck
puede decirle qué función asignó el valor, pero no más que eso, por lo general
muestra la ubicación de origen de la llave de apertura de la función. Entonces deberías
compruebe cuidadosamente que todas las variables locales de la función estén inicializadas correctamente.

Gastos generales de rendimiento: el seguimiento del origen es caro. Reduce a la mitad la velocidad de Memcheck y
aumenta el uso de memoria en un mínimo de 100 MB, y posiblemente más. Sin embargo puede
Reducir drásticamente el esfuerzo requerido para identificar la causa raíz de los
errores de valor, por lo que a menudo es una ganancia de productividad del programador, a pesar de ejecutar más
despacio.

Precisión: Memcheck rastrea los orígenes con bastante precisión. Para evitar espacios y tiempos muy grandes.
gastos generales, se hacen algunas aproximaciones. Es posible, aunque poco probable, que
Memcheck informará un origen incorrecto o no podrá identificar ningún origen.

Tenga en cuenta que la combinación --track-origins = sí y --undef-value-errors = no is
absurdo. Memcheck busca y rechaza esta combinación al inicio.

--cargas-parciales-ok = [defecto: sí]
Controla cómo Memcheck maneja cargas alineadas naturalmente de 32, 64, 128 y 256 bits desde
direcciones para las que algunos bytes son direccionables y otros no. Cuando si, tal
las cargas no producen un error de dirección. En cambio, los bytes cargados que se originan de ilegal
Las direcciones están marcadas como no inicializadas y las correspondientes a direcciones legales son
manejado de la manera normal.

Cuándo no, las cargas de direcciones parcialmente inválidas se tratan de la misma manera que las cargas de
Direcciones completamente inválidas: se emite un error de dirección ilegal y el resultado
los bytes están marcados como inicializados.

Tenga en cuenta que el código que se comporta de esta manera infringe los estándares ISO C / C ++,
y debe considerarse roto. Si es posible, dicho código debe corregirse.

--expensive-definition-checks = [defecto: No]
Controla si Memcheck debe emplearse de manera más precisa pero también más costosa (tiempo
consumiendo) algoritmos al comprobar la definición de un valor. La configuración predeterminada es
no hacer eso y suele ser suficiente. Sin embargo, para código altamente optimizado
valgrind a veces puede quejarse incorrectamente. Invocando valgrind con
--expensive-definition-checks = sí ayuda, pero tiene un costo de rendimiento. Tiempo de ejecución
Se ha observado una degradación del 25% pero el costo adicional depende mucho de la
aplicación a mano.

--keep-stacktraces = alloc | free | alloc-and-free | alloc-then-free | none [defecto:
aloc-and-free]
Controla qué seguimiento (s) de pila se deben mantener para los bloques mallocded y / o free'd.

En nuestro asignar-entonces-libre, se registra un seguimiento de la pila en el momento de la asignación y se asocia
con el bloque. Cuando se libera el bloque, se registra un segundo seguimiento de pila, y este
reemplaza el seguimiento de la pila de asignación. Como resultado, cualquier error "use after free" relacionado
a este bloque solo puede mostrar un seguimiento de la pila de dónde se liberó el bloque.

En nuestro aloc-y-libre, tanto la asignación como el seguimiento de la pila de desasignación para el bloque
se almacenan. Por lo tanto, un error "use after free" mostrará ambos, lo que puede generar el error
más fácil de diagnosticar. En comparación con asignar-entonces-libre, este ajuste aumenta ligeramente
El uso de memoria de Valgrind como bloque contiene dos referencias en lugar de una.

En nuestro asignar, solo se registra (y se informa) el seguimiento de la pila de asignación. Con gratis,
solo se registra (y se informa) el seguimiento de la pila de desasignación. Estos valores algo
disminuir la memoria de Valgrind y el uso de la CPU. Pueden ser útiles según el error.
tipos que está buscando y el nivel de detalle que necesita para analizarlos. Para
Por ejemplo, si solo le interesan los errores de fuga de memoria, es suficiente registrar
las trazas de la pila de asignación.

En nuestro ninguna, no se registran seguimientos de pila para malloc y operaciones gratuitas. Si tu
El programa asigna una gran cantidad de bloques y / o asigna / libera de muchas pilas diferentes
trazas, esto puede disminuir significativamente la CPU y / o la memoria requerida. Por supuesto, pocos
se informarán los detalles de los errores relacionados con los bloques de pila.

Tenga en cuenta que una vez que se registra un seguimiento de la pila, Valgrind mantiene el seguimiento de la pila en la memoria
incluso si ningún bloque hace referencia a él. Algunos programas (por ejemplo, recursivo
algoritmos) pueden generar una gran cantidad de seguimientos de pila. Si Valgrind usa demasiado
memoria en tales circunstancias, puede reducir la memoria requerida con las opciones
--mantener rastros de pila y / o usando un valor menor para la opción --num-callers.

--freelist-vol = [defecto: 20000000]
Cuando el programa cliente libera memoria usando gratis (en C) o borrar (C ++), esa memoria
no está disponible inmediatamente para reasignación. En cambio, está marcado
inaccesible y colocado en una cola de bloques liberados. El propósito es diferir mientras
posible el punto en el que la memoria liberada vuelve a circular. Esta
aumenta la posibilidad de que Memcheck pueda detectar accesos no válidos a bloques
durante un período significativo de tiempo después de haber sido liberados.

Esta opción especifica el tamaño total máximo, en bytes, de los bloques en la cola.
El valor predeterminado es veinte millones de bytes. Aumentar esto aumenta la cantidad total
de memoria utilizada por Memcheck, pero puede detectar usos no válidos de bloques liberados que
de lo contrario, pasará desapercibido.

--freelist-big-blocks = [defecto: 1000000]
Al hacer que los bloques de la cola de bloques liberados estén disponibles para reasignación,
Memcheck en prioridad recirculará los bloques con un tamaño mayor o igual a
--freelist-grandes-bloques. Esto asegura que la liberación de grandes bloques (en particular la liberación
bloques más grandes que --lista libre-vol) no conduce inmediatamente a una recirculación de
todos (o muchos) los bloques pequeños de la lista gratuita. En otras palabras, esta opción
aumenta la probabilidad de descubrir punteros colgantes para los bloques "pequeños", incluso
cuando se liberan grandes bloques.

Establecer un valor de 0 significa que todos los bloques se recirculan en un orden FIFO.

--workaround-gcc296-bugs = [defecto: No]
Cuando está habilitado, suponga que lee y escribe una pequeña distancia debajo del puntero de la pila
se deben a errores en GCC 2.96 y no los informa. La "pequeña distancia" es 256
bytes por defecto. Tenga en cuenta que GCC 2.96 es el compilador predeterminado en algunos sistemas Linux antiguos.
distribuciones (RedHat 7.X), por lo que es posible que deba utilizar esta opción. No lo use si
no es necesario, ya que puede provocar que se pasen por alto errores reales. Una mejor alternativa
es utilizar un GCC más reciente en el que se corrigió este error.

Es posible que también deba usar esta opción cuando trabaje con GCC 3.X o 4.X en 32 bits
PowerPC Linux. Esto se debe a que GCC genera código que ocasionalmente accede a continuación
el puntero de pila, especialmente para conversiones de números enteros de punto flotante a / desde. Esta
infringe la especificación PowerPC ELF de 32 bits, que no prevé
ubicaciones debajo del puntero de la pila para que sea accesible.

--show-desigualched-frees = [defecto: sí]
Cuando está habilitado, Memcheck comprueba que los bloques de pila se desasignan mediante una función que
coincide con la función de asignación. Es decir, espera gratis para ser usado para desasignar
bloques asignados por malloc, borrar para bloques asignados por newy Eliminar[] for
bloques asignados por nuevo[]. Si se detecta una discrepancia, se informa de un error. Esto es en
general importante porque en algunos entornos, liberar con una función no coincidente
puede provocar accidentes.

Sin embargo, existe un escenario en el que tales desajustes no se pueden evitar. Ahí es cuando el
el usuario proporciona implementaciones de new/nuevo[] esa llamada malloc y de borrar/Eliminar[]
esa llamada gratis, y estas funciones están alineadas asimétricamente. Por ejemplo, imagina
que Eliminar[] está en línea pero nuevo[] no es. El resultado es que Memcheck "ve" todo
Eliminar[] llamadas como llamadas directas a gratis, incluso cuando la fuente del programa no contiene
llamadas no coincidentes.

Esto genera muchos informes de errores confusos e irrelevantes.
--show-desigualched-frees = no desactiva estos controles. Generalmente no es aconsejable
deshabilítelos, sin embargo, porque puede perder errores reales como resultado.

--ignorar-rangos = 0xPP-0xQQ [, 0xRR-0xSS]
Todos los rangos enumerados en esta opción (y se pueden especificar múltiples rangos, separados por
comas) serán ignorados por la verificación de direccionabilidad de Memcheck.

--malloc-fill =
Llena los bloques asignados por malloc, new, etc., pero no por calloc, con el especificado
byte. Esto puede resultar útil cuando se intenta solucionar oscuros problemas de corrupción de la memoria.
Memcheck aún considera que el área asignada no está definida; solo esta opción
afecta su contenido. Tenga en cuenta que - relleno de malloc no afecta un bloque de memoria cuando
se usa como argumento para las solicitudes del cliente VALGRIND_MEMPOOL_ALLOC o
VALGRIND_MALLOCLIKE_BLOCK.

--free-fill =
Rellena los bloques liberados por free, delete, etc, con el valor de byte especificado. Esto puede ser
útil cuando se trata de solucionar oscuros problemas de corrupción de la memoria. La zona liberada es
Memcheck aún lo considera válido para el acceso; esta opción solo afecta a su
contenido. Tenga en cuenta que - relleno libre no afecta a un bloque de memoria cuando se utiliza como
argumento a las solicitudes del cliente VALGRIND_MEMPOOL_FREE o VALGRIND_FREELIKE_BLOCK.

CACHEGRIND OPCIONES

--I1 = , , tamaño>
Especifique el tamaño, la asociatividad y el tamaño de línea de la caché de instrucciones de nivel 1.

--D1 = , , tamaño>
Especifique el tamaño, la asociatividad y el tamaño de línea de la caché de datos de nivel 1.

--LL = , , tamaño>
Especifique el tamaño, la asociatividad y el tamaño de línea de la caché de último nivel.

--cache-sim = no | sí [sí]
Habilita o deshabilita la recopilación de acceso a la caché y recuentos de errores.

--branch-sim = no | sí [No]
Habilita o deshabilita la recopilación de instrucciones de rama y recuentos de predicciones erróneas. Por
por defecto, esto está deshabilitado ya que ralentiza Cachegrind en aproximadamente un 25%. Tenga en cuenta que
no puedes especificar --cache-sim = no y --branch-sim = no juntos, ya que eso dejaría
Cachegrind sin información para recopilar.

--cachegrind-out-file =
Escriba los datos del perfil en un archivo en lugar de en el archivo de salida predeterminado,
cachegrind.out. . los %p y %q Los especificadores de formato se pueden utilizar para incrustar el proceso.
ID y / o el contenido de una variable de entorno en el nombre, como es el caso de la
opción central --archivo de registro.

LLAMADA OPCIONES

--callgrind-out-file =
Escriba los datos del perfil en un archivo en lugar de en el archivo de salida predeterminado,
callgrind.out. . los %p y %q Los especificadores de formato se pueden utilizar para incrustar el proceso.
ID y / o el contenido de una variable de entorno en el nombre, como es el caso de la
opción central --archivo de registro. Cuando se realizan varios volcados, se modifica el nombre del archivo
más lejos; vea abajo.

--dump-line = [defecto: sí]
Esto especifica que el recuento de eventos debe realizarse con la granularidad de la línea de origen.
Esto permite la anotación de fuentes para fuentes que se compilan con información de depuración.
(-g).

--dump-instr = [defecto: No]
Esto especifica que el recuento de eventos debe realizarse con granularidad por instrucción.
Esto permite la anotación de código ensamblador. Actualmente, los resultados solo se pueden mostrar
por KCachegrind.

--compress-strings = [defecto: sí]
Esta opción influye en el formato de salida de los datos del perfil. Especifica si
Las cadenas (nombres de archivos y funciones) deben identificarse con números. Esto encoge el
archivo, pero hace que sea más difícil de leer para los humanos (lo cual no se recomienda en ningún
caso).

--compress-pos = [defecto: sí]
Esta opción influye en el formato de salida de los datos del perfil. Especifica si
Las posiciones numéricas siempre se especifican como valores absolutos o se permiten
en relación con los números anteriores. Esto reduce el tamaño del archivo.

--combine-dumps = [defecto: No]
Cuando está habilitado, cuando se van a generar múltiples partes de datos de perfil, estas partes son
adjunto al mismo archivo de salida. No recomendado.

--dump-every-bb = [defecto: 0, Nunca]
Volcar datos de perfil cada contar bloques básicos. Solo se comprueba si se necesita un volcado
cuando se ejecuta el planificador interno de Valgrind. Por tanto, el ajuste mínimo útil es
alrededor de 100000. El recuento es un valor de 64 bits para hacer posibles largos períodos de volcado.

--dump-before =
Volcar al entrar función.

--zero-before =
Cero todos los costos al ingresar función.

--dump-after =
Volcar al salir función.

--instr-atstart = [defecto: sí]
Especifique si desea que Callgrind comience la simulación y la creación de perfiles desde el principio de
el programa. Cuando se establece en no, Callgrind no podrá recopilar ninguna información,
incluidas las llamadas, pero tendrá como máximo una ralentización de alrededor de 4, que es el mínimo
Valgrind arriba. La instrumentación se puede habilitar de forma interactiva a través de callgrind_control
-yo en.

Tenga en cuenta que el gráfico de llamadas resultante probablemente no contendrá principal, pero lo hará
contienen todas las funciones ejecutadas después de que se habilitó la instrumentación. Instrumentación
También se puede habilitar / deshabilitar programáticamente. Consulte el archivo de inclusión de Callgrind callgrind.h
para la macro que debe usar en su código fuente.

Para la simulación de caché, los resultados serán menos precisos al encender la instrumentación
más adelante en la ejecución del programa, ya que el simulador comienza con un caché vacío en ese momento.
Active la recopilación de eventos más tarde para hacer frente a este error.

--collect-atstart = [defecto: sí]
Especifique si la recopilación de eventos está habilitada al comienzo de la ejecución del perfil.

Para ver solo partes de su programa, tiene dos posibilidades:

1. Ponga a cero los contadores de eventos antes de ingresar a la parte del programa que desea perfilar y descargue
los contadores de eventos a un archivo después de salir de esa parte del programa.

2. Active / desactive el estado de recopilación según sea necesario para ver solo los contadores de eventos.
mientras está dentro de la parte del programa que desea perfilar.

La segunda opción se puede utilizar si la parte del programa que desea perfilar se llama muchos
veces. La opción 1, es decir, crear muchos volcados no es práctica aquí.

El estado de la colección se puede alternar al entrar y salir de una función determinada con la opción
- alternar-recolectar. Si usa esta opción, el estado de la colección debe estar deshabilitado en el
comienzo. Tenga en cuenta que la especificación de - alternar-recolectar establece implícitamente
--collect-state = no.

El estado de la colección también se puede alternar insertando la solicitud del cliente
CALLGRIND_TOGGLE_COLLECT; en las posiciones de código necesarias.

--toggle-collect =
Alternar colección a la entrada / salida de función.

--collect-jumps = [defecto: No]
Esto especifica si se debe recopilar información para los saltos (condicionales). Como
arriba, callgrind_annotate actualmente no puede mostrarle los datos. Tienes que usar
KCachegrind para obtener flechas de salto en el código anotado.

--collect-systime = [defecto: No]
Esto especifica si se debe recopilar información para los tiempos de llamada del sistema.

--collect-bus = [defecto: No]
Esto especifica si se debe recopilar el número de eventos de bus global ejecutados.
El tipo de evento "Ge" se utiliza para estos eventos.

--cache-sim = [defecto: No]
Especifique si desea realizar una simulación de caché completa. De forma predeterminada, solo se leen instrucciones
se contabilizarán los accesos ("Ir"). Con la simulación de caché, más contadores de eventos son
habilitado: Caché falla en lecturas de instrucciones ("I1mr" / "ILmr"), accesos de lectura de datos ("Dr")
y fallas de caché relacionadas ("D1mr" / "DLmr"), accesos de escritura de datos ("Dw") y caché relacionada
fallas ("D1mw" / "DLmw"). Para obtener más información, consulte Cachegrind: una caché y una rama
perfilador de predicciones.

--branch-sim = [defecto: No]
Especifique si desea realizar una simulación de predicción de rama. Más contadores de eventos son
habilitado: Número de bifurcaciones condicionales ejecutadas y errores de predictores relacionados
("Bc" / "Bcm"), saltos indirectos ejecutados y fallas relacionadas del predictor de dirección de salto
("Bi" / "Bim").

HELGRIND OPCIONES

--free-is-write = no | sí [defecto: No]
Cuando está habilitado (no el predeterminado), Helgrind trata la liberación de memoria del montón como si el
La memoria se escribió inmediatamente antes que la libre. Esto expone razas donde la memoria está
referenciado por un hilo y liberado por otro, pero no hay
evento de sincronización para asegurar que la referencia ocurra antes que la libre.

Esta funcionalidad es nueva en Valgrind 3.7.0 y se considera experimental. Está
no habilitado de forma predeterminada porque su interacción con los asignadores de memoria personalizados no es
bien entendido en la actualidad. Se agradecen los comentarios de los usuarios.

--track-lockorders = no | sí [defecto: sí]
Cuando está habilitado (el valor predeterminado), Helgrind realiza una verificación de coherencia de la orden de bloqueo. Para
algunos programas con errores, la gran cantidad de errores de orden de bloqueo informados puede convertirse
molesto, especialmente si solo te interesan los errores de carrera. Por lo tanto, puede
le resultará útil deshabilitar la verificación de orden de bloqueo.

--history-level = none | approx | full [defecto: lleno]
--history-level = completo (el valor predeterminado) hace que Helgrind recopile suficiente información sobre
accesos "antiguos" que pueden producir dos seguimientos de pila en un informe de carrera, tanto la pila
el seguimiento del acceso actual y el seguimiento del acceso conflictivo anterior. Para
limitar el uso de memoria, los accesos "antiguos", los seguimientos de la pila están limitados a un máximo de 8 entradas,
aunque --num-callers el valor es mayor.

La recopilación de dicha información es costosa tanto en velocidad como en memoria, particularmente para
programas que realizan muchos eventos de sincronización entre subprocesos (bloqueos, desbloqueos, etc.).
Sin esa información, es más difícil rastrear las causas fundamentales de las razas.
No obstante, es posible que no lo necesite en situaciones en las que solo desee verificar el
presencia o ausencia de razas, por ejemplo, al hacer pruebas de regresión de un
anteriormente programa libre de carreras.

--history-level = ninguno es el extremo opuesto. Hace que Helgrind no recolecte ninguna
información sobre accesos anteriores. Esto puede ser dramáticamente más rápido que
--history-level = completo.

--history-level = aprox. proporciona un compromiso entre estos dos extremos. Causa
Helgrind para mostrar un seguimiento completo para el acceso posterior e información aproximada
con respecto al acceso anterior. Esta información aproximada consta de dos pilas y
Se garantiza que el acceso anterior se produjo en algún lugar entre los puntos del programa.
denotado por las dos pilas. Esto no es tan útil como mostrar la pila exacta para el
acceso anterior (como --history-level = completo hace), pero es mejor que nada, y
es casi tan rápido como --history-level = ninguno.

--conflict-cache-size = N [defecto: 1000000]
Esta bandera solo tiene efecto en --history-level = completo.

La información sobre accesos conflictivos "antiguos" se almacena en un caché de tamaño limitado,
con gestión de estilo LRU. Esto es necesario porque no es práctico almacenar un
seguimiento de pila para cada acceso a la memoria realizado por el programa. Información histórica
en ubicaciones a las que no se ha accedido recientemente se descarta periódicamente para liberar espacio en el
cache.

Esta opción controla el tamaño de la caché, en términos de la cantidad de memoria diferente
direcciones para las que se almacena información de acceso conflictiva. Si encuentras eso
Helgrind muestra errores de carrera con solo una pila en lugar de las dos esperadas
pilas, intente aumentar este valor.

El valor mínimo es 10,000 y el máximo es 30,000,000 (treinta veces el valor predeterminado
valor). Aumentar el valor en 1 aumenta el requisito de memoria de Helgrind en muy
aproximadamente 100 bytes, por lo que el valor máximo consumirá fácilmente tres gigabytes adicionales aproximadamente
de la memoria

--check-stack-refs = no | sí [defecto: sí]
De forma predeterminada, Helgrind verifica todos los accesos a la memoria de datos realizados por su programa. Esta bandera
le permite omitir la comprobación de accesos a pilas de subprocesos (variables locales). Esto puede
mejorar el rendimiento, pero tiene el costo de perder carreras en los datos asignados a la pila.

--ignore-thread-creation = [defecto: No]
Controla si se deben ignorar todas las actividades durante la creación de subprocesos. Por defecto
habilitado solo en Solaris. Solaris proporciona mayor rendimiento, paralelismo y
escalabilidad que otros sistemas operativos, a costa de un bloqueo más detallado
actividad. Esto significa, por ejemplo, que cuando se crea un hilo en glibc, solo uno
Big Lock se utiliza para todas las configuraciones de subprocesos. Solaris libc utiliza varios bloqueos detallados
y el hilo creador reanuda sus actividades lo antes posible, dejando por ejemplo
pila y secuencia de configuración de TLS al hilo creado. Esta situación confunde a Helgrind
ya que asume que existe un orden falso entre el creador y el creado
hilo; y por lo tanto, muchos tipos de condiciones de carrera en la aplicación no serían
informó. Para evitar este tipo de pedidos falsos, esta opción de línea de comando se establece en sí mediante
predeterminado en Solaris. Por lo tanto, se ignora toda la actividad (cargas, tiendas, solicitudes de clientes)
durante:

· Llamada pthread_create () en el hilo del creador

· Fase de creación del hilo (configuración de pila y TLS) en el hilo creado

Además, la memoria nueva asignada durante la creación de subprocesos no se rastrea, es decir, informes de carrera
se suprime allí. DRD hace lo mismo implícitamente. Esto es necesario porque
Solaris libc almacena en caché muchos objetos y los reutiliza para diferentes subprocesos y eso
confunde a Helgrind.

DRD OPCIONES

--check-stack-var = [defecto: No]
Controla si DRD detecta carreras de datos en variables de pila. Verificando las variables de la pila
está deshabilitado de forma predeterminada porque la mayoría de los programas no comparten variables de pila en
roscas.

- umbral-exclusivo = [defecto: apagado]
Imprima un mensaje de error si cualquier mutex o bloqueo de escritura se ha mantenido más tiempo que el tiempo
especificado en milisegundos. Esta opción habilita la detección de contención de bloqueos.

--join-list-vol = [defecto: 10]
Carreras de datos que ocurren entre una declaración al final de un hilo y otro hilo
puede perderse si la información de acceso a la memoria se descarta inmediatamente después de que un hilo se ha
se ha unido. Esta opción permite especificar cuántos subprocesos unidos hay en la memoria.
la información de acceso debe ser retenida.

--first-race-only = [defecto: No]
Ya sea para informar solo la primera carrera de datos que se ha detectado en una ubicación de memoria
o todas las carreras de datos que se han detectado en una ubicación de memoria.

--free-is-write = [defecto: No]
Ya sea para informar carreras entre el acceso a la memoria y la liberación de memoria. Habilitando esto
La opción puede hacer que DRD se ejecute un poco más lento. Notas:

· No habilite esta opción cuando utilice asignadores de memoria personalizados que utilizan
VG_USERREQ__MALLOCLIKE_BLOCK y VG_USERREQ__FREELIKE_BLOCK porque eso
resultar en falsos positivos.

· No habilite esta opción cuando utilice objetos contados por referencias porque eso
dar lugar a falsos positivos, incluso cuando ese código se ha anotado correctamente con
ANNOTATE_HAPPENS_BEFORE y ANNOTATE_HAPPENS_AFTER. Ver, por ejemplo, la salida del
el siguiente comando para un ejemplo: valgrind --tool = drd --free-is-write = yes
drd / tests / annotate_smart_pointer.

--report-signal-unlocked = [defecto: sí]
Ya sea para reportar llamadas a pthread_cond_signal y pthread_cond_broadcast donde el
mutex asociado con la señal a través de pthread_cond_wait or
pthread_cond_timed_waitno está bloqueado en el momento en que se envía la señal. Enviando una señal
sin mantener un bloqueo en el mutex asociado es un error de programación común que puede
causar condiciones de carrera sutiles y un comportamiento impredecible. Existen algunos poco comunes
patrones de sincronización, sin embargo, donde es seguro enviar una señal sin mantener un
bloquear en el mutex asociado.

--segment-merging = [defecto: sí]
Controla la fusión de segmentos. La fusión de segmentos es un algoritmo para limitar el uso de memoria del
algoritmo de detección de carrera de datos. La desactivación de la fusión de segmentos puede mejorar la precisión de
los llamados 'otros segmentos' que se muestran en los informes de carrera, pero también pueden desencadenar una salida
de error de memoria.

--segment-merging-interval = [defecto: 10]
Realice la fusión de segmentos solo después de que se haya completado el número especificado de nuevos segmentos.
creado. Esta es una opción de configuración avanzada que permite elegir si desea
Minimice el uso de memoria de DRD eligiendo un valor bajo o para permitir que DRD se ejecute más rápido
eligiendo un valor ligeramente superior. El valor óptimo para este parámetro depende de la
programa que se analiza. El valor predeterminado funciona bien para la mayoría de los programas.

--shared -reshold = [defecto: apagado]
Imprima un mensaje de error si el bloqueo del lector se mantuvo durante más tiempo que el tiempo especificado
(en milisegundos). Esta opción habilita la detección de contención de bloqueos.

--show-confl-seg = [defecto: sí]
Muestra segmentos conflictivos en los informes de carrera. Dado que esta información puede ayudar a encontrar el
causa de una carrera de datos, esta opción está habilitada de forma predeterminada. Deshabilitar esta opción hace
la salida de DRD más compacta.

--show-stack-uses = [defecto: No]
Uso de la pila de impresión en el momento de la salida del hilo. Cuando un programa crea una gran cantidad de
subprocesos, se vuelve importante limitar la cantidad de memoria virtual asignada para
pilas de hilo. Esta opción permite observar cuánta memoria de pila se ha
utilizado por cada hilo del programa cliente. Nota: la propia herramienta DRD asigna algunos
datos temporales en la pila de subprocesos del cliente. El espacio necesario para estos datos temporales.
debe ser asignado por el programa cliente cuando asigna memoria de pila, pero no
incluido en el uso de la pila informado por DRD.

--ignore-thread-creation = [defecto: No]
Controla si se deben ignorar todas las actividades durante la creación de subprocesos. Por defecto
habilitado solo en Solaris. Solaris proporciona mayor rendimiento, paralelismo y
escalabilidad que otros sistemas operativos, a costa de un bloqueo más detallado
actividad. Esto significa, por ejemplo, que cuando se crea un hilo en glibc, solo uno
Big Lock se utiliza para todas las configuraciones de subprocesos. Solaris libc utiliza varios bloqueos detallados
y el hilo creador reanuda sus actividades lo antes posible, dejando por ejemplo
pila y secuencia de configuración de TLS al hilo creado. Esta situación confunde DRD ya que
asume que existe un orden falso entre el creador y el hilo creado; y
por lo tanto, no se informarán muchos tipos de condiciones de carrera en la aplicación. Para
evitar este tipo de pedidos falsos, esta opción de línea de comando se establece en sí de forma predeterminada en
Solaris. Por lo tanto, toda la actividad (cargas, tiendas, solicitudes de clientes) se ignora durante:

· Llamada pthread_create () en el hilo del creador

· Fase de creación del hilo (configuración de pila y TLS) en el hilo creado

--trace-addr = [defecto: ninguno]
Rastree toda la actividad de la carga y la tienda para la dirección especificada. Esta opción puede ser
especificado más de una vez.

--ptrace-addr = [defecto: ninguno]
Rastree toda la actividad de carga y almacenamiento para la dirección especificada y continúe haciéndolo incluso
después de que la memoria en esa dirección se haya liberado y reasignado.

--trace-alloc = [defecto: No]
Rastree todas las asignaciones y desasignaciones de memoria. Puede producir una gran cantidad de producción.

--trace-barrera = [defecto: No]
Rastree toda la actividad de la barrera.

--trace-cond = [defecto: No]
Rastrear toda la actividad de la variable de condición.

--trace-fork-join = [defecto: No]
Rastree toda la creación de subprocesos y todos los eventos de terminación de subprocesos.

--trace-hb = [defecto: No]
Rastrear la ejecución de ANNOTATE_HAPPENS_BEFORE (), ANNOTATE_HAPPENS_AFTER () y
ANNOTATE_HAPPENS_DONE () solicitudes del cliente.

--trace-mutex = [defecto: No]
Rastrea toda la actividad de mutex.

--trace-rwlock = [defecto: No]
Rastree toda la actividad de bloqueo de lector-escritor.

--trace-semaphore = [defecto: No]
Rastrea toda la actividad del semáforo.

MASIVO OPCIONES

--heap = [defecto: sí]
Especifica si se debe realizar la generación de perfiles de almacenamiento dinámico.

--heap-admin = [defecto: 8]
Si la generación de perfiles de pila está habilitada, proporciona el número de bytes administrativos por bloque a
usar. Debe ser una estimación del promedio, ya que puede variar. Por ejemplo, el
El asignador utilizado por glibc en Linux requiere entre 4 y 15 bytes por bloque,
dependiendo de varios factores. Ese asignador también requiere espacio de administrador para liberar
bloques, pero Massif no puede dar cuenta de esto.

--stacks = [defecto: No]
Especifica si se debe realizar la generación de perfiles de pila. Esta opción ralentiza Massif
en gran medida, por lo que está desactivado de forma predeterminada. Tenga en cuenta que Massif asume que la pila principal tiene
tamaño cero al inicio. Esto no es cierto, pero hacer lo contrario con precisión es difícil.
Además, comenzar en cero indica mejor el tamaño de la parte de la pila principal
sobre el que un programa de usuario realmente tiene control.

--pages-as-heap = [defecto: No]
Le dice a Massif que perfile la memoria a nivel de página en lugar de en el bloque mal ubicado
nivel. Consulte más arriba para obtener más detalles.

--depth = [defecto: 30]
Profundidad máxima de los árboles de asignación registrados para instantáneas detalladas. Aumentándolo
hará que Massif se ejecute algo más lento, use más memoria y produzca una salida más grande
archivos.

--alloc-fn =
Las funciones especificadas con esta opción se tratarán como si fueran un montón
función de asignación como malloc. Esto es útil para funciones que son envoltorios para
malloc or new, que puede llenar los árboles de asignación con información poco interesante.
Esta opción se puede especificar varias veces en la línea de comando, para nombrar múltiples
funciones.

Tenga en cuenta que la función nombrada solo se tratará de esta manera si es la entrada superior en un
stack trace, o justo debajo de otra función tratada de esta manera. Por ejemplo, si tienes
Una función malloc1 que envuelve mallocy malloc2 que envuelve malloc1, solo especificando
--alloc-fn = malloc2 no tendrá ningún efecto. Necesitas especificar --alloc-fn = malloc1 as
bien. Esto es un poco inconveniente, pero la razón es que la verificación de la asignación
funciones es lento, y ahorra mucho tiempo si Massif puede dejar de mirar a través del
apilar las entradas de seguimiento tan pronto como encuentre una que no coincida en lugar de tener que
Continúe con todas las entradas.

Tenga en cuenta que los nombres de C ++ se demandan. Tenga en cuenta también que los nombres de C ++ sobrecargados deben escribirse
en su totalidad. Las comillas simples pueden ser necesarias para evitar que la cáscara las rompa.
Por ejemplo:

--alloc-fn = 'operador nuevo (sin firmar, estándar :: nothrow_t const &)'

--ignore-fn =
Cualquier asignación directa de montón (es decir, una llamada a malloc, new, etc., o una llamada a una función
nombrado por un --alloc-fn opción) que ocurre en una función especificada por esta opción
ser ignorado. Esto es sobre todo útil para realizar pruebas. Esta opción se puede especificar
varias veces en la línea de comando, para nombrar varias funciones.

Cualquiera reasignar de un bloque ignorado también será ignorado, incluso si el reasignar la llamada hace
no ocurre en una función ignorada. Esto evita la posibilidad de tamaños de pila negativos
si los bloques ignorados se encogen con reasignar.

Las reglas para escribir nombres de funciones en C ++ son las mismas que para --alloc-fn anterior.

--threshold = [defecto: 1.0]
El umbral de importancia para las asignaciones de montón, como porcentaje del tamaño total de la memoria.
Se agregarán las entradas del árbol de asignación que representen menos de esto. Tenga en cuenta que
esto debe especificarse junto con la opción de ms_print del mismo nombre.

--peak-inexactitud = [defecto: 1.0]
Massif no registra necesariamente el pico de asignación de memoria global real; por
Por defecto, registra un pico solo cuando el tamaño de la asignación de memoria global excede el
pico anterior en al menos un 1.0%. Esto se debe a que puede haber muchas asignaciones locales
picos a lo largo del camino, y hacer una instantánea detallada de cada uno sería costoso
y derrochador, ya que todos menos uno serán descartados más tarde. Esta inexactitud puede ser
cambiado (incluso a 0.0%) a través de esta opción, pero Massif se ejecutará drásticamente más lento a medida que el
el número se acerca a cero.

- unidad de tiempo = [defecto: i]
La unidad de tiempo utilizada para la elaboración de perfiles. Hay tres posibilidades: instrucciones
ejecutado (i), que es bueno para la mayoría de los casos; tiempo real (reloj de pared) (ms, es decir
milisegundos), que a veces es útil; y bytes asignados / desasignados en el montón
y / o pila (B), que es útil para programas de ejecución muy corta y para pruebas
propósitos, porque es el más reproducible en diferentes máquinas.

--detailed-freq = [defecto: 10]
Frecuencia de instantáneas detalladas. Con --detailed-freq = 1, se detalla cada instantánea.

--max-instantáneas = [defecto: 100]
El número máximo de instantáneas registradas. Si se establece en N, para todos los programas excepto muy
las de corta duración, el número final de instantáneas estará entre N / 2 y N.

--massif-out-file = [defecto: macizo.out.% p]
Escriba los datos del perfil en un archivo en lugar de en el archivo de salida predeterminado,
macizo. . los %p y %q Los especificadores de formato se pueden utilizar para incrustar el ID del proceso.
y / o el contenido de una variable de entorno en el nombre, como es el caso de la
opción central --archivo de registro.

SGCHECK OPCIONES

Actualmente, no hay opciones de línea de comandos específicas de SGCheck.

bbv OPCIONES

--bb-out-file = [defecto: bb.out.% p]
Esta opción selecciona el nombre del archivo de vector de bloque básico. los %p y %q formato
Los especificadores se pueden utilizar para incrustar el ID del proceso y / o el contenido de un entorno.
variable en el nombre, como es el caso de la opción principal --archivo de registro.

--pc-out-file = [defecto: pc.out.% p]
Esta opción selecciona el nombre del archivo de PC. Este archivo contiene direcciones de contador de programa
e información sobre el nombre de la función para los distintos bloques básicos. Esto se puede utilizar junto
con el archivo de vector de bloque básico para avanzar rápidamente a través de nombres de funciones en lugar de solo
la instrucción cuenta. los %p y %q Los especificadores de formato se pueden utilizar para incrustar el proceso.
ID y / o el contenido de una variable de entorno en el nombre, como es el caso de la
opción central --archivo de registro.

--interval-size = [defecto: 100000000]
Esta opción selecciona el tamaño del intervalo que se utilizará. El valor predeterminado es 100 millones
instrucciones, que es un valor de uso común. Se pueden utilizar otros tamaños; menor
Los intervalos pueden ayudar a los programas con fases más detalladas. Sin embargo, un tamaño de intervalo más pequeño
puede dar lugar a problemas de precisión debido a los efectos de calentamiento (al avanzar rápidamente los distintos
Las características arquitectónicas no se inicializarán y se necesitarán algunos
instrucciones antes de que "se calienten" al estado en el que se encontraría una simulación completa sin
el avance rápido. Los tamaños de intervalo grandes tienden a mitigar esto).

--instr-cuenta-solo [defecto: No]
Esta opción le dice a la herramienta que solo muestre los totales de recuento de instrucciones y que no
generar el archivo de vector de bloque básico real. Esto es útil para depurar y para
recopilar información de recuento de instrucciones sin generar el vector de bloque básico grande
archivos.

LACAYO OPCIONES

--basic-count = [defecto: sí]
Cuando está habilitado, Lackey imprime las siguientes estadísticas e información sobre el
ejecución del programa cliente:

1. El número de llamadas a la función especificada por el --fnnombre opción (la predeterminada
es principal). Si se han eliminado los símbolos del programa, el recuento siempre será
cero.

2. El número de ramas condicionales encontradas y el número y proporción de
los tomados.

3. El número de supermanzanas ingresadas y completadas por el programa. Tenga en cuenta que debido a
optimizaciones realizadas por el JIT, este no es en absoluto un valor exacto.

4. El número de instrucciones de invitado (x86, amd64, ppc, etc.) y declaraciones de IR
ejecutado. IR es la representación intermedia similar a RISC de Valgrind a través de la cual todos
la instrumentación está hecha.

5. Razones entre algunos de estos recuentos.

6. El código de salida del programa cliente.

--detailed-count = [defecto: No]
Cuando está habilitado, Lackey imprime una tabla que contiene recuentos de cargas, tiendas y ALU
operaciones, diferenciadas por sus tipos de IR. Los tipos de IR se identifican por su IR
nombre ("I1", "I8", ... "I128", "F32", "F64" y "V128").

--trace-mem = [defecto: No]
Cuando está habilitado, Lackey imprime el tamaño y la dirección de casi todos los accesos a la memoria realizados por
el programa. Consulte los comentarios en la parte superior del archivo lacayo / lk_main.c para obtener más detalles.
sobre el formato de salida, cómo funciona y las imprecisiones en el seguimiento de la dirección. Nota
que esta opción produce inmensas cantidades de producción.

--trace-superblocks = [defecto: No]
Cuando está habilitado, Lackey imprime la dirección de cada superbloque (una sola entrada,
salida múltiple, fragmento lineal de código) ejecutado por el programa. Esto es principalmente de
interés para los desarrolladores de Valgrind. Vea los comentarios en la parte superior del archivo.
Lacayo / lk_main.c para obtener detalles sobre el formato de salida. Tenga en cuenta que esta opción produce
grandes cantidades de producción.

--fnname = [defecto: principal]
Cambia la función para la que se cuentan las llamadas cuando --basic-count = sí está especificado.

Utilice valgrind.bin en línea utilizando los servicios de onworks.net