使用libtool e gdb

Question

我正在做一个使用GNU autotools的项目，所以为了使用gdb调试代码，我在libtool中运行gdb：

libtool --mode=execute gdbtui foobar

有没有可能重新加载项目的修改版本，而不必退出gdb/libtool并重启？

Answer 1

libtool --mode=execute创建一个临时可执行文件，并将其传递给gdb。此可执行文件在重新构建时会被删除。诀窍是用下面这样的东西重新创建它

libtool --mode=execute echo ./hello

(Libtool将重新创建临时可执行文件，并将其名称传递给echo命令。您可以使用任何其他命令而不是echo，例如true来抑制输出，甚至是不存在的命令。)

要重新加载可执行文件，请使用gdb file命令文件。gdb在启动时会显示可执行的实名：

$ libtool --mode=execute gdb --args ./hello
...
Reading symbols from /path/to/.libs/lt-hello...done.
(gdb)

也可以通过gdb info inferiors命令显示：

(gdb) info inferiors 
  Num  Description       Executable        
* 1    <null>            /path/to/.libs/lt-hello

当然，还可以使用上面的echo命令。

Answer 2

要弄清楚你到底在问什么有点困难，但我希望我没弄错。

可以，您通常可以从gdb中再次运行调试过的命令，只要它是在第一个位置使用gdb启动的。事实上，这是gdb的常见工作流程。在一个窗口/标签/窗格中使用它来调试你的东西，在另一个窗口中修复代码，在第三个窗口中重新构建，等等。

gdb的一种开始方式是这样的：

# gdb --args command arg1 arg2 ...

另一个是：

# gdb command

在后一种情况下，您无论如何都只能从gdb提示符启动程序，如下所示。

(gdb) run arg1 arg2 ...

在前者中，参数是隐含的(并由gdb记住)。在这两种情况下，您都可以在事件发生后使用以下命令检索参数：

(gdb) show args

一旦你遇到、分析和修复了一个bug，通常就会重新构建程序，只使用run重新运行它(它重用了以前的参数)，然后验证修复或继续调试另一个问题。

Answer 3

基于@Ilia的回答(以及关于如何将可执行文件名称解析为gdb变量的this回答)，一个解决方案是在~/.gdbinit中定义以下custom make命令

define lmake
  python gdb.execute('set $f = "' + str(gdb.selected_inferior().progspace.filename) + '"')
  make
  eval "file %s", $f
end