4

I'm working on a project that uses GNU autotools, so in order to debug the code using gdb, I'm running gdb from within libtool:

libtool --mode=execute gdbtui foobar

Is it possible to reload a modified version of the project without the annoyance of having to quit gdb/libtool and restart?

user1404316
  • 463
  • 6
  • 11
  • 1
    For background, when a program is built using autotools, one can't debug it directly using gdb. See, for example: http://stackoverflow.com/questions/12148668/how-to-debug-a-program-wrapped-in-a-libtool-script – user1404316 Feb 28 '13 at 20:00

3 Answers3

2

libtool --mode=execute creates a temporary executable which is passed to gdb. This executable is removed upon rebuild. The trick is to recreate it with something like

libtool --mode=execute echo ./hello

(Libtool will recreate the temporary executable and pass its name to echo command. You can use any other command instead of echo, e.g. true to suppress output, or even non-existing one.)

To reload the executable use gdb filefilename command file. Executable real name is displayed by gdb upon start:

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

It is also displayed by gdb info inferiors command:

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

and, of course, by the above echo command.

Ilia K.
  • 4,822
  • 2
  • 22
  • 19
0

It is a bit difficult to discern what exactly you are asking, but I hope I understood you correctly.

Yes, you can normally run the debugged command again from within gdb as long as it was started with gdb in the first place. In fact this is the common workflow for gdb. Use it in one window/tab/pane to debug your stuff and fix the code in another, rebuild in a third etc.

One way gdb gets started is this one:

# gdb --args command arg1 arg2 ...

another is:

# gdb command

in the latter case you would anyway only start the program from the gdb prompt like this.

(gdb) run arg1 arg2 ...

in the former the arguments are implied (and remembered by gdb). In either case you can retrieve the arguments after the fact using:

(gdb) show args

It is common to rebuild the program once you hit, analyzed and fixed a bug re-run it using only run (which reuses the previous arguments) and verify the fix or continue debugging another problem.

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
  • 1
    But when a program is built using GNU autotools, one can't invoke gdb directly from the command line as you suggest. Rather, it's necessary to invoke gdb indirectly via 'libtool', as in the one-liner I put in my question. It's in that scenario my question stands. For background, refer to question http://stackoverflow.com/questions/12148668/how-to-debug-a-program-wrapped-in-a-libtool-script – user1404316 Feb 28 '13 at 19:56
  • @user1404316: and you tried running `show args` from within `gdb`? And yes, it *is* possible to run the ready program manually with `gdb` afterward. Not sure what you want, however, is at all possible. You should add those clarifications to your question, though. On the other hand why shouldn't you be able to separate the build and debug/execute stage *with* `libtool` and use the above method as I described it? Most times during debugging the library dependencies won't change, so you should still be fine with re-`run`ning the process. – 0xC0000022L Feb 28 '13 at 20:06
  • `libtool` by default only creates a shell script (that is named just like the binary) and the binary itself is put into the .libs/ subdirectory. The real binary will only appear after `make install` or when using `libtool --mode=execute`. See the answer from @Illia K. – Jens Mühlenhoff Dec 02 '16 at 21:30
  • This is all answered in the linked question: https://stackoverflow.com/questions/12148668/how-to-debug-a-program-wrapped-in-a-libtool-script?noredirect=1&lq=1 This question is kind of a follow up question, asking for the ability to reload the executable from within a gdb session. – Jens Mühlenhoff Dec 02 '16 at 21:32
0

Based on @Ilia's answer (and this answer on how to parse the executable name to a gdb variable) a solution is to define the following custom make command in ~/.gdbinit:

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