所述TLDR /摘要：有一种方法，给定两个可执行文件（两者都来自C ++编译，与调试信息存在，并且从相同或近乎相同的源代码），列出仅是，在一个不同的相对于所述的功能，另一个？
背景/动机：在每个冲刺结束，我们的工程团队手中“英雄”打造了我们的QA团队作为一个候选发布版。 SQA小组然后花几个人周测试的候选版本，以确保它正常工作。 （他们已经自动尽可能多的测试，因为他们可以的，但也有一些地方是不容易实现自动化，因此费力的手工测试/验证）。不可避免的是，他们遇到的候选版本的一个或多个故障，此时一个bug报告提交，工程修复的错误，并生成一个新的版本，候选人。
在这一点上，SQA团队必须做出决定：他们重新从头开始所有的测试，或者他们认为新版本，候选人是相同的，除了请求修复了以前版本的候选者 - 即，不回归在程序的其他部分进行了介绍？
第一种选择（“从头开始”）是安全的，但价格昂贵，并导致显著时间表打滑。第二个选择（“只是继续测试和以前一样，但随着新的建设”）是更快，但其回归风险漏网之鱼给用户，如果有新引入的故障出现在已经使用测试的程序部分老版本。
所以，当SQA问我的意见对这个决定的，我现在做一个“SVN DIFF”两个集结日期间，以检查正是C ++代码改变之间的两个版本，并用它来估计没有做一个完整的风险水平-retest。然而，我们的一些SQA人的不信任我们的构建过程和我一样多，他们也不愿意做，仅仅因为源代码几乎没有变化，这意味着可执行几乎没有变化的假设。 （即他们说：“但如果一些设置已经改变了构建机器，我们不知道的？”;而我只能呼吁他们对人性的信念，没有人会做这样的事）
因此，为了缓和SQA的恐惧（和我自己），这将是非常有用的，如果我能采取的新版本候补可执行文件，并做就可以了“差异”（与旧/部分测试的发布候选可执行文件），看看到底哪些功能是不同的，并且保持不变。 （很明显，我可以只使用二进制的差异或者MD5校验要做到这一点，但是这些只会告诉我，两个可执行文件是不同的，他们不会告诉我哪个功能是不同的，这是我真正想知道的 - 例如，经过我固定在关于盒一个错字，在可执行文件中的核心业务逻辑功能并没有改变相对于早期的测试）
我知道这个问题的答案很可能OS特定的;但是我们编译的Linux，MacOS的/ X和Linux下，所以对于任何这三个操作系统的任何有识之士将受到欢迎。
在这个问题的答案似乎是否定的，存在不存在任何此类工具（至少不反恶意软件社区之外）。
因此，只是为了看看这是可以做到的，我写了一个简单的证明了概念executable_diff实用程序，它或多或少什么，我一直在寻找。它运行在Linux下和MacOS / X，并且当调用它运行的每个所述两个可执行的通过反汇编器（“otool”在MacOS / X“ objdump的” Linux下），然后扫描拆卸文本看到其中的函数在文本 - 段（或在.RODATA段字符串）是一个可执行与下一个之间的不同。
然后，它打印出的清单，其功能是不相同的它们在其他可执行对口，也写出包含实际的diff的情况下，用户希望看到的功能是如何不同的文件。
在实施这个方案的主要复杂的因素是，当你改变一个函数的大小在程序中通过，因为所有的在文本段的变化还在后面，以及函数的地址的程序的其余部分是变化的涟漪。因此，程序还包含逻辑（做DIFF之前通过在装配转换绝对地址返回到它们相应的函数名）过滤出假阳性
由于在这个问题上的评论者所指出的，版本比较可执行文件是使用版本控制和跟踪每个生成的可执行文件相关联的存储库修订号的，这样就可以在源代码级做你的diff，而不是不可替代的。我写这个只是看它是否可以做，作为一个学习锻炼自己教更多关于源代码的更改如何反映在所得到的二进制文件。 executable_diff应该只是一个粗略的启发式考虑，因为这无疑将产生在某些情况下假阳性和错误地忽略他人有意义的变化。