"使用调试DCU"的编译器选项？

Question

在我写的一个组件中,我想包括自动检测已注册的图像格式,但它是一个只有在禁用Use Debug DCU的编译器选项时才有效的解决方案.

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

但就目前而言,我只想知道如何在运行时检查是否设置了Use Debug DCU的编译器选项.

Answer 1

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

该Use Debug DCUs编译器选项仅切换搜索路径; 编译器最终会发现什么是未知的.(误导)用户可能已将Release dcu复制到调试目录上,反之亦然.

即使没有误解用户,也可能会将一些文件添加到项目中(并使用项目进行编译)以包含一些错误修复.例如,如果用户已Graphics.pas添加到项目中,执行release/no-debug构建,但保留Use Debug DCU's编译器选项,那么Graphics.dcu实际链接的不是调试版本,因为它是使用可执行文件重新构建的.所以你得到一个"混合"的调试和非调试dcus包.

您可以尝试检测是否存在与某些对象或方法相关的调试信息,但这也是不可靠的:如果您使用"Build with Debug Dcus"但将"Debug Information"设置为false,那么您实际上是扔掉了调试信息,以便您不再查找它.

但是这个链接代码在Debug DCU上失败了

来自GLScene项目的代码不是一个好的黑客,它使用硬编码的偏移到代码中TPicture.RegisterFileFormat,然后继续使用硬编码的偏移量来获取全局FileFormats变量的地址(不调用GetFileFormats例程).那里的魔法数字太多了!

我的第一个问题是将TList使用该GLScene方法确定的方法与TList我已经确定的方法进行比较,但是猜测一下:在我的机器上没有问题,两种例程在两种情况下都得到了相同的结果.在我的机器上GLScene,原来的丑陋并没有被Debug DCU打破.

我甚至尝试过"指纹识别"一些rtl/vcl单元(SysUtils,Graphics,Classes); 我列出了所有公共类,为每个类中的每个方法生成了一些使用RTTI的代码,并将代码的前1024个字节转储到字符串文件中.使用Debug DCU和非Debug DCU运行该程序,我得到了相同的结果.我的文本文件包含3500种方法的指纹!

不是个好主意

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

唯一真正的选择是将一个可能失败的黑客替换为一个不会失败的黑客攻击(或至少以可控方式失败).