【问题标题】:How to delete dead code or code of no use based on configure file/makefile file如何根据配置文件/makefile文件删除死代码或无用代码
【发布时间】:2018-09-16 07:34:01
【问题描述】:

当我们编译一个 C/C++ 项目时,项目源中的一些文件和代码是不需要编译的。例如,测试文件夹(一些测试脚本)、示例文件夹和死代码。如何识别这些未编译为二进制文件的源文件?不希望编译是必要的。因为我需要自动处理很多项目,如果没有手动操作,很难编译所有项目。

我知道编译可以自动删除死代码,但在我的情况下我无法编译整个项目,并且在源代码中,还有许多其他代码没有参与最终编译,例如测试文件夹中的代码,工具文件夹中的代码...我希望能检测到这些代码,至于死代码,我知道静态分析很难检测到,所以不管它,只关心没有编译的整个文件和整个文件夹。

我为什么要这样做? 我想提取一些特征(字符串、函数调用图、int 常量...)来表示这个项目,并将这些特征与从二进制文件中提取的相同特征进行比较,看看有什么区别。因此,如果我从测试文件夹中的代码中提取功能并且代码未在最终的二进制文件中编译。比较这些特征会出现很大的误差。

【问题讨论】:

  • 既然你已经标记了cmake,那么就有一个简单的解决方案:多个目标。主可执行程序的一个目标,以及运行测试的程序的另一个目标。主要的可执行目标当然不会包含任何测试源。
  • 说明:为什么需要删除死代码?一般情况下可能是不可能的!如果一些死代码仍然存在,你会怎样?所以请edit你的问题。您应该在其中添加更多段落(带有动机和上下文)并显示一些minimal reproducible example
  • 目前尚不清楚您在这里实际要解决什么样的问题。该项目的开发人员不应列出编译不需要的文件以供编译,因此无需手动识别这些文件。或者您是否处于只有 .h 和 .cpp 文件并且需要弄清楚如何构建它们的情况?在这种情况下,没有任何简单的方法可以解决这个问题。

标签: c makefile cmake static-analysis


【解决方案1】:

当您向optimize 询问时,编译器通常会(但并非总是)消除死代码(但自动删除所有死代码是不可能的,因为undecidablehalting problem 等价)。请注意as-if rule 允许编译器进行此类优化。所以在实践中你不需要删除相应的源代码。

某些行业的编码规则(例如DO-178C)要求禁止死源代码。检测是极其困难的并且通常是不可能的(参见例如Rice's theorem),因此需要大量复杂的static program analysis 技术和外部code review 并且成本很高(例如将软件开发成本增加30 倍以上) .

您的 build automation 系统(例如 cmake 或 Makefile 等)可能是(并且通常是)Turing-complete;因此,即使删除完全无用的 C++ 源文件通常也是一项不可能完成的任务。即使是 POSIX shell(用于构建你的东西​​的命令)也很难分析(请参阅 Yann Regis-Gianas 在 FOSDEM2018 上出色的 Parsing Posix [S]hell 演讲)。

【讨论】:

  • DO178 中的死代码被定义为不满足任何顶级(系统)要求 (TLR) 或任何派生要求的代码。分析不需要识别/删除死代码,因为它可以——实际上通常会——朝着相反的方向工作:从 TLR 和派生需求开始,找到满足这些需求所需的代码。根据定义,通过这种分析达到的代码是活着的,而死代码只是通过没有被访问来排除。这是一个过于简单的描述,但关键是没有必要分析源代码将其标记为死代码以排除它。
猜你喜欢
  • 2012-11-07
  • 1970-01-01
  • 2013-09-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-04-24
  • 2011-04-01
  • 1970-01-01
相关资源
最近更新 更多