delphi – “使用调试DCU”的编译器选项？

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

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

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

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

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

我的第一个问题是将使用GLScene方法识别的TList与我确定的TList进行比较,但是猜测一下：在我的机器上没有问题,两种例程在两种情况下都得到了相同的结果.在我的机器上,GLScene虽然很丑,但是没有被Debug DCU打破.

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

不是个好主意

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

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