¿Cómo obtengo una llamada a los padres para obtener los símbolos libc6 (por ejemplo, _int_malloc) con Linux perf?

Question

Estoy perfilando una aplicación C++ utilizando linux perf, y estoy obteniendo un buen diagrama de flujo de control usando GProf2dot. Sin embargo, algunos símbolos de la biblioteca C (libc6-2.13.so) toman una parte sustancial del tiempo total y, sin embargo, no tienen bordes internos.

Por ejemplo:

• _int_malloc tarda 8% del tiempo, pero no tiene padres de llamadas.
• __strcmp_sse42 y __cxxabiv1::__si_class_type_info::__do_dyncast juntos tomar alrededor de 10% del tiempo, y tienen un llamador cuyo nombre es 0, que tiene las personas que llaman 2d6935c, 2cc748c y 6, que no tienen las personas que llaman.

Como resultado, no puedo averiguar qué rutinas son responsables de todo este mallocing y fundición dinámica utilizando simplemente perf. Sin embargo, parece que otros símbolos (por ejemplo, malloc pero no _int_malloc) tienen padres de llamada.

¿Por qué no perf show llama a los padres de _int_malloc? ¿Por qué no puedo encontrar las últimas llamadas de __do_dyn_cast? Y, ¿hay alguna forma de que modifique mi configuración para que pueda obtener esta información? Estoy en x86-64, así que me pregunto si necesito una libc6 (no estándar) con punteros de cuadro.

Answer 1

Actualización: A partir del kernel 3.7.0, se puede determinar padres de llamadas de símbolos en las bibliotecas del sistema usando perf record -gdwarf <command>.

Usando -gdwarf, no es necesario compilar con -fno-omit-frame-pointer.

Respuesta original: Sí, uno probablemente se necesitaría un libc6 compilado con los punteros de marco (-fno-omit-framepointer) en x86_64, en la actualidad (24 de mayo de 2012).

Sin embargo, los desarrolladores están trabajando actualmente para permitir que las herramientas de rendimiento utilicen la información de desenrollado de DWARF. Esto significa que ya no se necesitan punteros de marco para obtener información de rastreo en x86_64. Linus, sin embargo, no quiere un desbobinador DWARF en el kernel. Por lo tanto, las herramientas de ejecución guardarán registros a medida que el sistema se está ejecutando, y realizarán el desenrollado de DWARF en la herramienta de perforación del espacio de usuario utilizando la biblioteca libunwind.

Esta técnica ha sido probada para determinar con éxito las llamadas de (por ejemplo) malloc y dynamic_cast. Sin embargo, el conjunto de parches aún no está integrado en el kernel de Linux, y necesita someterse a una revisión adicional antes de que esté listo.

Answer 2

_int_malloc y __do_dyn_cast se invocan desde rutinas que el generador de perfiles no puede identificar porque no tienen información de tabla de símbolos para ellas.

Además, parece que está mostrando tiempo propio (exclusivo). Eso solo es útil para encontrar zonas interactivas en rutinas que a) tienen mucho tiempo de autoestima, yb) se puede arreglar.

Hay una razón por la que se crearon perfiles posteriores al original profil. El software real consiste en funciones que dedican casi todo el tiempo a llamar a otras funciones, y usted necesita poder encontrar el código que está en la pila la mayor parte del tiempo, y no el contador del programa la mayor parte del tiempo.

Así que debe configurar perf para tomar muestras de la pila y decirle el porcentaje de cada uno de sus rutinas están en la pila. Es incluso mejor si informa no solo rutinas, sino líneas de código, como en Zoom. Lo mejor es tomar las muestras en la hora del reloj de pared, para que no esté ciego a IO.

There's more to say on all this.