【问题标题】：Compiler option for "Use Debug DCU's"?“使用调试 DCU”的编译器选项？
【发布时间】：2013-02-03 17:05:56
【问题描述】：

在我正在编写的组件中，我想包含automatic detection of registered image formats，但这是一个仅在禁用使用调试 DCU 的编译器选项时才有效的解决方案。

我真正想知道的是这个解决方案的替代方案，它不涉及编译器选项依赖性。

但目前，我只想知道如何在运行时检查是否设置了 Use Debug DCU's 编译器选项。

【问题讨论】：

如果不使用 IDE 怎么办？命令行构建。
AFAICT，选中该选项只会将提供给编译器的路径更改为 VCL/RTL dcu 文件。它实际上并没有改变任何其他东西，例如范围检查或其他选项。我不确定是否有任何方法可以检测到组件中的路径更改。
@KenWhite，它改变了分配：链接到“调试”DCU 的可执行文件具有不同版本的代码，更多测试，更少优化；如果低级 hack 依赖于一些硬编码的偏移量来获取它想要的数据，那么不同的布局将会带来不同的世界。
@CosminPrund 我没有看黑客。您很好地找出了真正的问题并提出了解决方案。
@NGLN 为什么需要在设计时知道？然后执行的Graphics 单元是IDE 加载的VCL 包中的单元。并且调试 DCU 被禁用。它与该编译器选项的设置无关。

标签： delphi compiler-options

【解决方案1】：

没有可靠的方法在运行时获取该信息

Use Debug DCUs 编译器选项只切换搜索路径；编译器最终会发现什么是未知的。（被误导的）用户可能已将 Release dcu 复制到调试目录中，反之亦然。

即使没有错误的用户，也可能会将一些文件添加到项目中（并与项目一起编译）以包含一些错误修复。例如，如果用户将Graphics.pas 添加到项目中，执行发布/无调试构建，但保留Use Debug DCU's 编译器选项，则实际链接的Graphics.dcu 不是调试构建，因为它是用可执行文件重新构建。所以你会得到一个“混合”的调试和非调试 dcus。

您可以尝试检测是否存在与某些对象或方法相关的调试信息，但这也是不可靠的：如果您使用“使用 Debug Dcus 构建”，然后将“调试信息”设置为 false，那么您基本上就是丢弃调试信息，以便您不再寻找它。

但该链接代码在调试 DCU 上失败

来自 GLScene 项目的代码不是一个好的 hack，它使用硬编码的偏移量到 TPicture.RegisterFileFormat 的代码中，然后继续使用硬编码的偏移量来获取全局 FileFormats 变量的地址（不调用GetFileFormats 例程）。里面的魔法数字太多了！

我的第一个想法是将使用 GLScene 方法识别的 TList 与我识别的 TList 进行比较，但猜猜看：在我的机器上都没有问题在这两种情况下，例程都得到了相同的结果。在我的机器上，GLScene，虽然丑陋，但并没有被 Debug DCU 破坏。

我什至尝试过“指纹识别”一些 rtl/vcl 单元（SysUtils、Graphics、Classes）；我列出了所有公共类，为每个类中的每个方法生成了一些使用 RTTI 的代码，并将代码的前 1024 个字节转储到字符串文件中。使用调试 DCU 和非调试 DCU 运行该程序，我得到了相同的结果。我的文本文件包含大约 3500 种方法的指纹！

不是个好主意

由于该选项不会真正影响编译器的编译方式（仅影响链接器链接的内容），因此创建依赖于该选项的代码非常不可靠，也不是一个好主意。 这只影响低级黑客攻击，并且您不希望在您完全无法控制的情况下可能会导致应用程序崩溃的低级黑客攻击。

唯一真正的选择是用不会失败（或至少以可控方式失败）的黑客替换可能失败的黑客攻击。

【讨论】：

【解决方案2】：

作为Ken comments，可能无法检测此编译器选项涉及的路径更改。命令行编译器documentation 没有提到编译器开关，因此意味着它根本不存在。如果没有编译器开关，则无法检查是否设置了该编译器选项

...但它是一种仅在 Use Debug DCU's 编译器选项被禁用时才有效的解决方案。

如果仅有效意味着否则会导致异常，那么您可以使用以下替代方法：

try
  // AutoDetectRegisteredImageFormats
except
  // Handle case when Use Debug DCU's is on
end;

【讨论】：

这也没有回答所提出的问题。