我正在尝试创建一种将C ++项目的调试信息传输到远程位置进行测试的方法。在当前的开发周期中，对代码的微小更改需要传输整个二进制文件（大小为100s MB，主要是调试信息）。
目前我解决这个问题的方法是使用-gsplit-dwarf将调试信息从目标文件（其大小没有调试信息在我的连接上可管理）中分离出来，然后将调试文件与一个副本区分开来。目前在远程盒子上构建。
目标是为项目的调试文件提供一组补丁，以便可以在远程位置调试新代码。远程位置和本地计算机之间的连接速度很慢，因此最小化修补程序的大小是最重要的，但它也应该与工具的运行时间平衡。我已经研究过bsdiff和xdelta作为潜在的解决方案并遇到了一个难题，其中xdetla速度很快但是太大而且bsdiff在大小方面是完美的，但运行时间和内存要求比我想要的要高一些。
我是否缺少一种工具或方法，或者我只是采用了错误的方法？也许是bsdiff和xdelta的替代品？我知道像gbdserver这样的工具在这种情况下不会起作用，因为我们对实际调试有一些要求。可以对bsdiff进行一些改动来帮助提高性能吗？事实上，如果我使用的方法是合理的，那么在远程机器上保留构建副本的好方法是什么。
答案 0 :(得分：0)
最简单的方法是使用＆＃34; strip＆＃34;将debuginfo复制到一个单独的＆＃34; .debug＆＃34;文件，然后使用＆＃34; strip＆＃34;再次从您将部署的可执行文件中删除调试信息。 ＆＃34; strip＆＃34;手册解释了如何做到这一点，寻找＆＃34; - only-keep-debug＆＃34;选项。
执行此操作后，您可以通过各种方式告诉gdb单独的调试信息。最好的方法是使用＆＃34; build-id＆＃34;特征。这就是现代Linux发行版所做的。然而，还有其他方法。 gdb手册中有关于单独调试文件的整个部分。
这里的关键点是你可以在剥离的可执行文件上启动gdb，它会自动找到单独的调试信息。这些数据都可以是本地数据，因此您不需要部署调试信息。
如果您仍然关心缩小调试信息，即使完成此操作，您也可以查看＆＃34; dwz＆＃34;工具。这是一个DWARF压缩器。然而，这通常只有在您计划将调试信息发送到某处时才会发生 - 发行版使用它来更轻松地下载调试信息，但普通用户并不能真正看到需要。