LibreOffice:确定负责打印的源代码部分

时间:2014-01-09 22:12:29

标签: linux code-analysis libreoffice call-graph callgrind

我正在尝试为LibreOffice打印过程实现一些额外的功能(一些特殊信息应自动添加到每个打印页面的边距)。我正在使用RHEL 6.4和LibreOffice 4.0.4以及Gnome 2.28。

我的目的是研究LibreOffice和系统组件之间的数据流,并确定哪些源代码负责打印。之后,我将不得不修改这些代码部分。

现在我需要有关源代码研究方法的建议。从我的角度来看,我找到了很多工具:

  1. strace似乎非常低级别;
  2. gprof需要使用“-pg”CFLAGS重新编译二进制文件;不知道如何使用LibreOffice;
  3. systemtap只能探测系统调用,不是吗?
  4. callgrind + Gprof2Dot非常好,但表现不佳(见下文);
  5. 例如,此处是来自callgrind输出的调用图,其中Gprof2Dot可视化。我用这样的命令开始callgrind

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

    并收到四个输出文件:

    -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
    

    最后一个(pid 29812)对应于正在运行的LibreOffice Writer GUI应用程序(我用straceps aux确定它)。我按 CTRL + P 和OK按钮。然后我关闭了应用程序,希望看到负责在日志中打印流程初始化的功能。

    根据此答案,使用callgrind工具处理Gprof2Dot输出。不幸的是,我无法在图片上看到我感兴趣的动作,也不能看到调用图。

    对于解决此类问题的正确方法的任何信息,我将不胜感激。谢谢。

    enter image description here

2 个答案:

答案 0 :(得分:1)

解决此问题的正确方法是记住LibreOffice是开源的。记录完整的源代码,您可以在docs.libreoffice.org浏览文档。不要那么努力:)

此外,请记住,打印机设置对话框不是特定于LibreOffice的,而是由操作系统提供。

答案 1 :(得分:1)

您想要的是识别感兴趣的源代码的工具。测试覆盖率(TC)工具可以提供此信息。

TC程序执行的操作是确定运行程序时运行的代码片段;把它想象为收集代码区域。通常,TC工具与(交互/单元/集成/系统)测试结合使用,以确定测试的有效性。如果只执行了少量代码(由TC工具检测到),则测试被解释为无效或不完整;如果覆盖了很大比例,那么就有一个很好的测试,以及运输产品的合理理由(假设所有测试都已通过)。

但您可以使用TC工具查找实现功能的代码。首先,您执行一些测试(或者可能手动驱动软件)来执行感兴趣的功能,并收集TC数据。如果使用了该功能,它会告诉您所有已执行代码的集合;这是对您感兴趣的代码的过高估计。然后你运动程序,要求它做一些类似的活动,但不执行该功能。这标识了绝对不实现该功能的代码集。计算代码运用功能和......的集合差异,而无需确定更专注于支持功能的代码。

通过运行更多练习功能,你可以自然地获得更紧密的界限,而不是那些练习功能和计算这些集合的联盟的差异。

有C ++的TC工具,例如" gcov"。我认为,他们中的大多数人都不会让/帮助你在结果上计算这样的设定差异;许多TC工具似乎没有任何操作覆盖集的支持。 (我的公司制作了一系列具有此功能的TC工具,包括计算覆盖率设置差异,包括C ++)。

如果您确实想提取相关代码,则TC工具不会这样做。 它们只是通过在源文件中指定文本区域来告诉您什么代码。大多数测试覆盖率工具仅报告涵盖的作为此类文本区域;这部分是因为许多测试覆盖工具使用的机器仅限于编译器记录的行号。

但是,在启动文件/行/列到结束文件/行/列方面,人们可以拥有精确报告文本区域的测试覆盖率工具(嗯,我公司的工具碰巧会这样做)。有了这些信息,构建一个简单的程序来读取源文件并从字面上提取已执行的代码是相当简单的。 (这并不意味着提取的代码是一个格式良好的程序!例如,虽然有必要,但数据声明不会被包含在已执行的片段中。)

OP并没有说出他打算用这些代码做什么,所以片段集可能就是所需要的。如果他想提取代码和必要的声明,他将需要更复杂的工具来确定所需的声明。具有完整解析器和源代码名称解析器的程序转换工具可以为此提供必要的功能。这比使用临时提取文本提取的测试覆盖工具要复杂得多。