LibreOffice :déterminer la partie du code source responsable de l'impression

Question

J'essaie d'implémenter des fonctionnalités supplémentaires au processus d'impression LibreOffice (certaines informations spéciales doivent être ajoutées automatiquement dans les marges de chaque page imprimée).J'utilise RHEL 6.4 avec LibreOffice 4.0.4 et Gnome 2.28.

Mon objectif est de rechercher le flux de données entre LibreOffice et les composants du système et de déterminer quels codes sources sont responsables de l'impression.Après cela, je devrai modifier ces parties de code.

Maintenant, j'ai besoin d'un conseil sur les méthodes de recherche de code source.J'ai trouvé plein d'outils et de mon point de vue :

1. strace semblent être de très bas niveau ;
2. gprof nécessite des binaires recompilés avec "-pg" CFLAGS ;je ne sais pas comment le faire avec LibreOffice ;
3. systemtap peut sonder uniquement les appels système, n'est-ce pas ?
4. callgrind + Gprof2Dot sont plutôt bons ensemble mais donnent des résultats étranges (voir ci-dessous) ;

Par exemple, voici le graphique des appels de callgrind sortie avec Gprof2Dot visualisation.J'ai commencé callgrind avec une telle commande :

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

et reçu quatre fichiers de sortie :

-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

Le dernier (pid 29812) correspond à l'application graphique LibreOffice Writer en cours d'exécution (je l'ai déterminé avec strace et ps aux).J'ai pressé CTRL+P. et le bouton OK.Ensuite, j'ai fermé l'application en espérant voir la fonction responsable de l'initialisation du processus d'impression dans les journaux.

Le callgrind la sortie a été traitée avec un Gprof2Dot outil selon cette réponse.Malheureusement, je ne vois sur la photo ni les actions qui m'intéressent, ni le graphique des appels tel quel.

J'apprécierai toute information sur la manière appropriée de résoudre un tel problème.Merci.

Answer 1

La bonne façon de résoudre ce problème est de se rappeler que LibreOffice est open source.L'intégralité du code source est documenté et vous pouvez parcourir la documentation sur docs.libreoffice.org.Ne faites pas ça à la dure :)

En outre, n'oubliez pas que la boîte de dialogue de configuration de l'imprimante n'est pas spécifique à LibreOffice, mais qu'elle est fournie par le système d'exploitation.

Answer 2

Ce que vous voulez, c'est un outil pour identifier le code source qui vous intéresse.Les outils de couverture de test (TC) peuvent fournir ces informations.

Ce que font les outils TC, c'est déterminer quels fragments de code ont été exécutés, lorsque le programme est exercé ;considérez-le comme une collecte comme un ensemble de régions de code.Normalement, les outils TC sont utilisés conjointement avec des tests (interactifs/unités/intégration/système), pour déterminer l'efficacité des tests.Si seule une petite quantité de code a été exécutée (telle que détectée par l'outil TC), les tests sont interprétés comme inefficaces ou incomplets ;si un pourcentage important a été couvert, on dispose de bons tests et d'une justification raisonnable pour l'expédition du produit (en supposant que tous les tests ont réussi).

Mais vous pouvez utiliser les outils TC pour trouver le code qui implémente les fonctionnalités.Tout d'abord, vous exécutez un test (ou peut-être pilotez manuellement le logiciel) pour exercer la fonctionnalité qui vous intéresse et collectez des données TC.Ceci vous indique l'ensemble de tout le code exercé, si la fonctionnalité est utilisée ;c'est une surestimation du code qui vous intéresse.Ensuite, vous exercez le programme en lui demandant d'effectuer une activité similaire, mais qui n'exerce pas la fonctionnalité.Cela identifie l'ensemble de code qui n'implémente certainement pas la fonctionnalité.Calculez la différence définie entre le code exercé avec la fonctionnalité et ... sans pour déterminer le code qui est plus axé sur la prise en charge de la fonctionnalité.

Vous pouvez naturellement obtenir des limites plus strictes en exécutant plus de fonctionnalités d'exercices et plus de fonctionnalités sans exercice et en calculant les différences sur les unions de ces ensembles.

Il existe des outils TC pour C++, par exemple "gcov".La plupart d'entre eux, je pense, ne vous laisseront pas / ne vous aideront pas à calculer de telles différences entre les résultats ;de nombreux outils TC ne semblent pas prendre en charge la manipulation des ensembles couverts.(Mon entreprise crée une famille d'outils TC dotés de cette capacité, y compris le calcul des différences d'ensemble de couverture, y compris C++).

Si tu veux vraiment extrait le code correspondant, les outils TC ne font pas cela.Ils vous indiquent simplement quel code en désignant des zones de texte dans les fichiers source.La plupart des outils de couverture de test ne couvrent que le rapport lignes en tant que telles, des régions de texte ;cela est en partie dû au fait que les machines utilisées par de nombreux outils de couverture de test sont limitées aux numéros de ligne enregistrés par le compilateur.

Cependant, on peut disposer d'outils de couverture de test précis dans la déclaration des régions de texte en termes de début de fichier/ligne/colonne jusqu'à fin de fichier/ligne/colonne (hum, les outils de mon entreprise le font).Avec ces informations, il est assez simple de créer un programme simple pour lire les fichiers sources et extraire littéralement le code qui a été exécuté.(Cela ne signifie pas que le code extrait est un programme bien formé !par exemple, les déclarations de données ne seront pas incluses dans les fragments exécutés alors qu'elles sont nécessaires).

OP ne dit pas ce qu'il a l'intention de faire avec un tel code, donc l'ensemble de fragments peut suffire.S'il souhaite extraire le code et les déclarations nécessaires, il aura besoin d'outils plus sophistiqués capables de déterminer les déclarations nécessaires.Les outils de transformation de programme avec des analyseurs complets et des résolveurs de noms pour le code source peuvent fournir les capacités nécessaires à cet effet.C'est considérablement plus compliqué à utiliser que de simples outils de couverture de test avec extraction de texte ad hoc.