Actualmente estoy tratando de perfilar una biblioteca compartida precargada usando la variable de entorno LD_PROFILE.
Compilo la biblioteca con el indicador "-g" y exporto LD_PROFILE_OUTPUT y LD_PROFILE antes de ejecutar una aplicación (ncat en mi caso) con la biblioteca precargada. Entonces, más precisamente lo que hago es lo siguiente:
export LD_PROFILE_OUTPUT=`pwd`export LD_PROFILE=libexample.soLD_PRELOAD=`pwd`/libexample.so ncat ... La precarga en sí funciona y se usa mi biblioteca, pero no se crea ningún archivo libexample.so.profile. Si uso export LD_PROFILE=libc.so.6 en su lugar, hay un archivo libc.so.6.profile como se esperaba.
¿Es este un problema de combinar LD_PRELOAD y LD_PROFILE o hay algo que podría haber hecho mal?
Estoy usando glibc v2.12 en CentOS 6.4 si eso tiene alguna relevancia.
¡Muchas gracias!
Lo siento, no sé la respuesta de por qué LD_PROFILE no funciona con LD_PRELOAD.
Sin embargo, para crear perfiles de binarios compilados con -g, me gusta mucho la herramienta valgrind junto con la herramienta gráfica kcachegrind.
valgrind --tool=callgrind /path/to/some/binary con opciones
creará un archivo llamado algo así como callgrind.out.1234 donde 1234 fue el pid del programa cuando se ejecutó. Ese archivo se puede analizar con:
kcachegrind callgrind.out.1234
En kcachegrind, verá fácilmente en qué funciones se gasta la mayor parte del tiempo de la CPU, el mapa de llamadas también muestra esto de una manera gráfica agradable. El gráfico de llamadas puede ayudar a comprender cómo funciona el programa. Incluso podrá mirar el código fuente para ver cuánto tiempo de CPU se gasta en cada línea.
Espero que encuentre útil valgrind aunque esta no fue la respuesta a su pregunta LD_PROFILE. El inconveniente de valgrind es que ralentiza las cosas tanto cuando se usa para crear perfiles como para verificar la memoria.