35

According to this excellent guide one should be able to recompile a source file and simply use 'r' to have gdb begin debugging the new, changed binary.

This also seemed implied in the gdb manual by "If the modification time of your symbol file has changed since the last time GDB read its symbols, GDB discards its symbol table, and reads it again."

I am trying to debug a simple, single .cpp file on Ubuntu 16.10. After compiling via g++ -ggdb -std=c++11 foo.cpp, I can debug as usual.

GNU gdb (Ubuntu 7.11.90.20161005-0ubuntu2) 7.11.90.20161005-git
[...]
(gdb) break main
Breakpoint 1 at 0x2754: file foo.cpp, line 204.
(gdb) r
Starting program: /home/code/foo

Breakpoint 1, main () at foo.cpp:204
(gdb) n
(gdb) k
Kill the program being debugged? (y or n) y

Here, I make a minor change to source file and then recompile. When trying to run the file again:

(gdb) r
/home/code/foo' has changed; re-reading symbols.
Error in re-setting breakpoint 1: Cannot access memory at address 0x55555555674b
Starting program: /home/code/598
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.

[Inferior 1 (process 20898) exited normally]

Is there a way to successfully reload the binary while keeping my breakpoints intact?

EDIT: This post had the answer I was looking for. You reload the executable with the file binaryname command.

(gdb) file foo
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
A program is being debugged already.
Load new symbol table from "foo"? (y or n) y
Reading symbols from foo...done.
Error in re-setting breakpoint 1: Cannot access memory at address 0x274b
Error in re-setting breakpoint 2: Cannot access memory at address 0x274b

We see the breakpoints are still there, just disabled:

(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep n   0x0000555555556754
        breakpoint already hit 1 time
2       breakpoint     keep n   0x000055555555677b

And so we just enable them:

(gdb) enable
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000555555556754 
        breakpoint already hit 1 time
2       breakpoint     keep y   0x000055555555677b
(gdb)

This works, but I would love to hear if anyone has further advice or input on whether simply using run should indeed work.

user280937
  • 462
  • 1
  • 5
  • 11
  • 1
    The breakpoint was probably on a location that is no longer valid with your new code. And remember that even it still is in a valid location, it might not be the same location as you expect. – Some programmer dude Mar 26 '18 at 09:24
  • Also, please think about your title to the question you posted. The question is not really about reloading the program, but about keeping the breakpoints. – Some programmer dude Mar 26 '18 at 09:25
  • Edited with the solution, which indeed has existed in GDB for a long time. The breakpoint was valid, the examples shown were a single character difference in the source. I could find no other references or questions regarding reloading the same binary, other than some guides that imply `(gdb) r` will magically reload everything. This is something those less familiar with gdb could encounter and have difficulties with. – user280937 Mar 26 '18 at 09:42
  • 1
    The plain `run` approach works for me. Why it is failing for you is something worth investigating. Perhaps file a gdb bug with details. – Tom Tromey Mar 26 '18 at 14:29
  • Just in case you need to reboot your computer https://stackoverflow.com/questions/501486/getting-gdb-to-save-a-list-of-breakpoints – n. m. could be an AI Dec 19 '18 at 20:49

3 Answers3

21

When I was using gdb 5, using just run after recompilation was enough to reload the symbols. Now, with gdb 8.1, I need to type file /path/to/executable before run in order to force gdb to reload the symbols after recompilation.

SAMPro
  • 1,068
  • 1
  • 15
  • 39
user61383
  • 311
  • 2
  • 7
  • In gdb 7.7 , I also need to run `file /PATH/TO/EXECUTABLE` before `run` command – Ham Jan 18 '22 at 04:46
  • I'm doing the same under gdb 12.1, but I specify the program via `--args` when running gdb. This seems to remove the need to use `file`. – mindoverflow Jul 25 '23 at 08:53
6

Here is a script I use in gdb 8.3 (slightly adapted for this answer):

define make
    shell make
    python gdb.execute("file " + gdb.current_progspace().filename)
    # clear cache
    directory
end

You need to have gdb w/Python. Note the directory command which updates the source files cache.

ampli
  • 141
  • 2
  • 7
5

The issue specifically with breakpoints and PIE seems to have been fixed in gdb 8.3.1 - see https://www.gnu.org/software/gdb/news/ and PR 25011.

Since the issue is due to position-independent executables (PIE), relinking the program with -no-pie should also get around it.

The issue that got me to this question was that automatic reloading of symbols seemed to have been broken in new gdb, but it seems that change was not in gdb but rather that Linux distributions started enabling PIE by default in gcc. Linking with -no-pie also fixed symbol reloading for me.

olsner
  • 981
  • 7
  • 6