LibreOffice:determinar la parte del código fuente responsable de la impresión

Question

Estoy intentando implementar alguna funcionalidad adicional al proceso de impresión de LibreOffice (alguna información especial debe agregarse automáticamente a los márgenes de cada página impresa).Estoy usando RHEL 6.4 con LibreOffice 4.0.4 y Gnome 2.28.

Mi propósito es investigar el flujo de datos entre LibreOffice y los componentes del sistema y determinar qué códigos fuente son responsables de la impresión.Después de eso tendré que modificar estas partes del código.

Ahora necesito un consejo sobre los métodos de investigación del código fuente.Encontré muchas herramientas y desde mi punto de vista:

1. strace parecen ser de muy bajo nivel;
2. gprof requiere binarios recompilados con "-pg" CFLAGS;no tengo idea de cómo hacerlo con LibreOffice;
3. systemtap Sólo se pueden sondear llamadas al sistema, ¿no?
4. callgrind + Gprof2Dot son bastante buenos juntos pero producen resultados extraños (ver más abajo);

Por ejemplo, aquí está el gráfico de llamadas de callgrind salida con Gprof2Dot visualización.Yo empecé callgrind con tal comando:

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes /usr/lib64/libreoffice/program/soffice --writer

y recibió cuatro archivos de salida:

-rw-------.   1 root  root          0 Jan  9 21:04 callgrind.out.29808
-rw-------.   1 root  root     427196 Jan  9 21:04 callgrind.out.29809
-rw-------.   1 root  root     482134 Jan  9 21:04 callgrind.out.29811
-rw-------.   1 root  root     521713 Jan  9 21:04 callgrind.out.29812

El último (pid 29812) corresponde a la aplicación GUI de LibreOffice Writer en ejecución (lo determiné con strace y ps aux).Yo presioné CONTROL+PAG y el botón Aceptar.Luego cerré la aplicación con la esperanza de ver la función responsable de la inicialización del proceso de impresión en los registros.

El callgrind La salida fue procesada con un Gprof2Dot herramienta de acuerdo con esta respuesta.Desafortunadamente, no puedo ver en la imagen ni las acciones que me interesan ni el gráfico de llamadas tal como está.

Agradeceré cualquier información sobre la forma adecuada de resolver dicho problema.Gracias.

Answer 1

La forma adecuada de resolver este problema es recordar que LibreOffice es de código abierto.Todo el código fuente se documenta y puede buscar documentación en docs.libreoffice.org .No hagas eso de la manera difícil :)

Además, recuerde que el cuadro de diálogo Configuración de la impresora no es específico de LibreOffice, más bien, es proporcionado por el sistema operativo.

Answer 2

Lo que desea es una herramienta para identificar el código fuente de interés. Las herramientas de cobertura de prueba (TC) pueden proporcionar esta información.

¿Qué hacen las herramientas de TC es determinar qué fragmentos de código se han ejecutado, cuando se ejerce el programa? Piense en ello como recolección como conjunto de regiones de código. Normalmente, las herramientas TC se utilizan junto con las pruebas (interactivas / unidades / integración / sistema), para determinar qué tan efectivas son las pruebas. Si solo se ha ejecutado una pequeña cantidad de código (según lo detectado por la herramienta TC), las pruebas se interpretan como ineficaces o incompletas; Si se ha cubierto un gran porcentaje, uno tiene buenas pruebas de ASD Justificación razonable para enviar el producto (asumiendo todas las pruebas aprobadas).

Pero puede usar TC TOUS TOUS para encontrar el código que implementa las funciones. Primero, ejecuta algunas pruebas (o tal vez impulsan manualmente el software) para ejercer la función de interés y recopilar datos de TC. Esto le indica el conjunto de todo el código ejercido, si se usa la función; Es una sobreestimación del código de interés para usted. Luego, ejerce el programa, pidiéndole que haga algo de actividad similar, pero que no ejerce la característica. Esto identifica el conjunto de código que definitivamente no implementa la función. Calcule la diferencia establecida de la función de ejercicios de código y ...- sin determinar el código que está más enfocado en la función de soporte.

Naturalmente, puede obtener límites más ajustes al ejecutar más ejercicios, característica y más no, no tenga en cuenta la característica y las diferencias informáticas sobre los sindicatos de esos conjuntos.

Hay herramientas TC para C ++, por ejemplo, "GCOV". La mayoría de ellos, creo, no la dejará / ayudarlo a calcular tales diferencias establecidas sobre los resultados; Muchas herramientas de TC parecen tener ningún soporte para manipular conjuntos cubiertos. (Mi compañía realiza una familia de herramientas TC que tienen esta capacidad, incluidas las diferencias de cobertura de cóbegación, incluyendo C ++).

Si realmente desea extraer el código relevante, TC Tools no hace eso. Simplemente le dicen qué código designando regiones de texto en los archivos de origen. La mayoría de las herramientas de cobertura de prueba solo reportan cubiertas líneas como tales regiones de texto; Esto se debe en parte a que la maquinaria, muchas herramientas de cobertura de prueba se limitan a los números de línea registrados por el compilador.

Sin embargo, uno puede tener herramientas de cobertura de prueba que sean precisas en la presentación de regiones de texto en términos de iniciar archivo / línea / columna al archivo / línea / columna de finalización (AHEM, las herramientas de la compañía pueden hacer esto). Con esta información, es bastante sencillo crear un programa simple para leer los archivos de origen y extraer literalmente el código que se ejecutó. (¡Esto no significa que el código extraído sea un programa bien formado! Por ejemplo, las declaraciones de datos no se incluirán en los fragmentos ejecutados aunque son necesarios).

OP no dice lo que pretende hacer con dicho código, por lo que el conjunto de fragmentos puede ser todo lo que se necesita. Si quiere extraer el código y las declaraciones necesarias, necesitará herramientas más sofisticadas que puedan determinar las declaraciones necesarias. Las herramientas de transformación del programa con parsers completos y resolores de nombres para el código fuente pueden proporcionar la capacidad necesaria para esto. Esto es considerablemente más complicado de usar que solo herramientas de cobertura de prueba con extracción de texto de extracción ad hoc.