当前位置: 技术问答>linux和unix
linux程序发布的时候都会保留一份符号表吗？
来源: 互联网 发布时间：2017-05-21
本文导语: 正常公司Linux程序的发布流程是？ 1、 g++ -o3 test.cpp -o test.exe 发布test.exe，保留源码，现场test.exe如果产生core。那么用保留的源码编译一份加-g的test_debug.exe，然后调试core。 2、 g++ -g3 -o3 test.cpp -o test_debug.exe objc...
正常公司Linux程序的发布流程是？
1、
发布test.exe，保留源码，现场test.exe如果产生core。那么用保留的源码编译一份加-g的test_debug.exe，然后调试core。
2、
发布test.exe，保留test_debug.symbol，现场test.exe如果产生core。那么用test_debug.symbol调试core。
现场产生的core文件可以通过1、2方案加载完整的调试信息，跟直接调试debug程序一样不？
1、
g++ -o3 test.cpp -o test.exe
发布test.exe，保留源码，现场test.exe如果产生core。那么用保留的源码编译一份加-g的test_debug.exe，然后调试core。
2、
g++ -g3 -o3 test.cpp -o test_debug.exe
objcopy --only-keep-debug test_debug.exe test_debug.symbol
objcopy --strip-debug test_debug.exe test.exe
发布test.exe，保留test_debug.symbol，现场test.exe如果产生core。那么用test_debug.symbol调试core。
现场产生的core文件可以通过1、2方案加载完整的调试信息，跟直接调试debug程序一样不？
|
如果你采用方案一，那么就存在一个风险，在你的代码release出去之后，在这过程中出现了代码修改（很常见），而这个时候就要依赖于，你们对code的版本管理，比如我们采用perforce管理code，可以关联一个buildnumber，然后当特定版本出现问题后，从perforce上再下载相应的code，采用-g编译出一份，然后分析core dump。
但这种做法，以我现在的理解，也无法确保不出现任何问题。但是很悲剧的是，我们的产品现在就是这么做的。但针对windows的产品，我知道公司内部一般都保留相应的pdb的。
有时候找不到相应的版本的时候，那就没办法了，只有编译带有-g的，在客户机器上重现问题了.....
如果再给我一次机会，我更倾向于方案2，理论上应该没有问题。
希望论坛中其他人能够给出他们的看法。。。。。。我也很想知道其他团队是怎么做的
但这种做法，以我现在的理解，也无法确保不出现任何问题。但是很悲剧的是，我们的产品现在就是这么做的。但针对windows的产品，我知道公司内部一般都保留相应的pdb的。
有时候找不到相应的版本的时候，那就没办法了，只有编译带有-g的，在客户机器上重现问题了.....
如果再给我一次机会，我更倾向于方案2，理论上应该没有问题。
希望论坛中其他人能够给出他们的看法。。。。。。我也很想知道其他团队是怎么做的
|
一般都能匹配上，主要我们出现core的情况也不多，而且问题一般不复杂，通过bt+code review基本就能发现问题。而且我们team windows上的产品，由于历史原因，每次也没有保留pdb，有时候也是编译出相应的一份，然后再用windbg强制加载非一致的pdb。
虽然我们这么做的，但是我不建议你们也这么做。因为我们是历史原因造成，并且产品基本稳定运行，很少有情况出现crash。如果你们是一个新的产品，或者还有更多的功能要去开发，那么建议采用方案二了。
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。