LibreOffice:determinar a origem de parte do código responsável por imprimir

Question

Estou tentando implementar algumas funcionalidades adicionais para o LibreOffice processo de impressão (algumas informações devem ser adicionadas automaticamente para as margens de cada página impressa).Eu estou usando o RHEL 6.4 com o LibreOffice 4.0.4 e o Gnome 2.28.

Meu propósito é o de investigar o fluxo de dados entre o LibreOffice e componentes do sistema e determinar quais códigos-fonte são responsáveis pela impressão.Depois que eu precisará modificar essas partes do código.

Agora eu preciso de um conselho sobre os métodos de código-fonte de pesquisa.Eu encontrei uma abundância de ferramentas e, do meu ponto de vista:

1. strace parecem ser de nível muito baixo;
2. gprof requer binários compilados com "- " pg " CFLAGS;não tem idéia de como fazê-lo com o Broffice;
3. systemtap pode sonda de chamadas de sistema só, não é?
4. callgrind + Gprof2Dot são muito bons juntos, mas realizar estranho resultados (ver abaixo);

Por exemplo, aqui está o gráfico de chamadas a partir de callgrind saída com Gprof2Dot visualização.Eu comecei a callgrind com um comando como:

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

e recebeu quatro arquivos de saída:

-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

O último (pid 29812) corresponde ao executar o LibreOffice Writer aplicativo GUI (i, determinado com strace e ps aux).Eu pressionei CTRL+P e o botão OK.Em seguida, fechei a aplicação esperando para ver a função de responsável pelo processo de impressão de inicialização em logs.

O callgrind a saída foi processada com um Gprof2Dot ferramenta de acordo com esta resposta.Infelizmente, eu não posso ver na imagem, nem a ação que eu estou interessado em, nem o grafo de chamadas como está.

Eu aprecio por qualquer informação sobre a maneira correta de resolver um problema tão grande.Obrigado.

Answer 1

A maneira correta de resolver este problema é lembrar-se de que o LibreOffice é open source.Todo o código-fonte documentado e que você pode procurar a documentação docs.libreoffice.org.Não faça isso da maneira mais difícil :)

Além disso, lembre-se que o diálogo de configuração da impressora não está LibreOffice-específico, em vez disso, é fornecido pelo sistema operacional.

Answer 2

O que você quer é uma ferramenta para identificar o código-fonte de interesse.Teste de Cobertura (TC) ferramentas pode fornecer essa informação.

O que o TC ferramentas fazer é determinar o que os fragmentos do código de ter de executar, quando o programa é exercida;pense nisso como a recolha de como conjunto de regiões de código.Normalmente TC ferramentas são utilizadas em conjunto com (interactive/unidade/integração/sistema) testes, para determinar a eficácia dos testes.Se apenas uma pequena quantidade de código foi executado (como detectado pelo TC ferramenta), os testes são interpretados como ineficaz ou incompleta;se um grande percentual foi coberto, tem bons testes asd uma justificação razoável para o envio do produto (supondo que todos os testes passados).

Mas você pode usar o TC ferramentas para encontrar o código que implementa recursos.Primeiro, você executar um teste (ou talvez manualmente unidade de software) para o exercício da característica de interesse, e recolher TC de dados.Isto indica o conjunto de todos os o código exercido, se o recurso é usado;é uma superestimação do código de interesse para você.Em seguida, você exercitar o programa, pedindo a ele para fazer alguma atividade semelhante, mas que não exerce a função.Isso identifica o conjunto de código que definitivamente não implementar o recurso.Calcular o conjunto diferença deste código, exercida com recurso e ...-sem para determinar o código que está mais focada em apoiar o recurso.

Você pode, naturalmente, obter mais apertados limites executando exercícios mais recursos e mais não-exercício-recurso de computação e diferenças entre os sindicatos desses conjuntos.

Há TC ferramentas para C++, por exemplo, "gcov".A maioria deles, eu acho, não deixe a/o ajudar a calcular tal conjunto de diferenças nos resultados;muitos TC ferramentas, parecem não ter qualquer suporte para a manipulação de cobertura de conjuntos.(A minha empresa faz uma família de TC ferramentas que têm esta capacidade, incluindo calcular a cobertura de conjunto de diferenças, incluindo C++).

Se você realmente quiser extrato de o código relevante, TC ferramentas não fazem isso.Eles simplesmente dizer-lhe que o código designando o texto regiões em arquivos de origem.A maioria de cobertura de teste apenas ferramentas de relatório coberto linhas como tal texto regiões;isto é em parte porque a maquinaria muitos de cobertura de teste ferramentas de uso é limitado a linha de números registrados pelo compilador.

No entanto, pode-se ter cobertura de teste ferramentas de que precisas no relatório o texto das regiões em termos de arquivo inicial/linha/coluna para acabar com a ficheiro/linha/coluna (ahem, minha empresa de ferramentas de acontecer para fazer isso).Com esta informação, é bastante simples para criar um simples programa para ler arquivos de origem, e extrair, literalmente, o código que foi executada.(Isso não significa que o extraídos código é bem formado programa!por exemplo, as declarações de dados não será incluído no executada fragmentos embora sejam necessárias).

OP não dizer o que ele pretende fazer com esse código, de modo que o conjunto de fragmentos pode ser tudo o que é necessário.Se ele quer extrair o código e as declarações necessárias, ele vai precisar de ferramentas mais sofisticadas que podem determinar as declarações necessárias.Programa ferramentas de transformação com analisadores completos e resolvedores de nome do código-fonte pode fornecer a necessária capacidade para isso.Isto é consideravelmente mais complicado de usar do que apenas a cobertura do teste de ferramentas com o ad hoc de extração de extração de texto.