如何在Linux上获取gdb,以便在windows上查找二进制交叉编译的源文件

Question

我正在尝试调试在Windows主机上针对Linux目标进行交叉编译的应用程序.

问题:因为初始编译是在Windows中,所以二进制文件中存储的源文件路径是这种形式C:\Users\foo\project\....在Linux目标上我已将源文件置于\home\foo\project\.... 默认情况下gdb由于路径不同而找不到源文件.

到目前为止我尝试了什么:

1. 在gdb中使用"directory"命令为正在调试应用程序的目标Linux系统中的.c源文件提供确切路径.这可行,但遗憾的是有数百个文件,所以这个解决方案是不现实的.

2. 使用该set substitute-path C:\\Users\\foo\\project /home/foo/project命令让gdb替换所有前缀.注意,\\似乎必须show substitute-path注册正确的字符串.遗憾的是,这不起作用.我的猜测是,substitute-path命令不处理ms-dos样式路径.

3. 尝试将调试信息分离到单独的.debug文件中(请参阅如何在构建目标之外生成gcc调试符号？),然后使用debugedit通过命令更改路径debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug.不幸的是,这也不起作用.debugedit如果现有的路径都是UNIX/Linux类似但似乎不适用于ms-dos样式路径,似乎工作正常.

我查看了stackoverflow,虽然有类似的主题我找不到任何可以帮助我的东西.非常感谢任何建议/帮助.我意识到从Windows进行交叉编译是一种非常迂回的方式,但目前还无法避免.

谢谢

Answer 1

虽然这是一个相当老的问题，但我确实遇到了同样的问题。我设法解决了它，但使用sed了二进制可执行文件...（是的，有点“黑客”风格，但没有找到其他方法）。我已经成功地sed替换了可执行文件内的符号路径，技巧是新路径的长度应该与旧路径的长度相同。

sed -i "s#C:/srcpath#/srcpath/.#g" ./executable

确保新路径的长度相同，否则可执行文件将中断。