Community
Participate
Working Groups
Build Identifier: CDT 8.0 I have an inlined function in a header file (no optimization turned on). I set a breakpoint there and start debug session. Breakpoint is not hit. Output from gdb traces: 82,702 9-file-exec-and-symbols --thread-group i1 /home/amueller/sources/HEAD/hello/Debug/hello 382,703 9^done 382,703 (gdb) 382,706 10-break-insert --thread-group i1 -f /home/amueller/sources/HEAD/hello/src/hello.h:7 382,706 &"No source file named /home/amueller/sources/HEAD/hello/src/hello.h.\n" 382,707 10^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending=\ "/home/amueller/sources/HEAD/hello/src/hello.h:7",times="0",original-location="/home/amueller/source\ s/HEAD/hello/src/hello.h:7"} Setting the breakpoint manually in the gdb console break /home/amueller/sources/HEAD/hello/src/hello.h:7 works flawlessly. Using CDI instead of DSF works, too. Reproducible: Always
Created attachment 203052 [details] Sample project Add a breakpoint in hello.h line 7 and start debug session.
I can reproduce this. The problem only happens if the breakpoint is already set at startup. If I set the bp after the launch has started, it works. The reason it works for CDI is that it uses -environment-directory. Also, using only the filename without the full path works. This is all gdb's behavior. So to summarize: Broken for full-path at startup > gdb.7.3 -q -batch /home/lmckhou/hello/Debug/hello -ex "b /home/lmckhou/hello/src/hello.h:7" No source file named /home/lmckhou/runtime-TestDSF/hello/src/hello.h. Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] Working for filename only > gdb.7.3 -q -batch /home/lmckhou/hello/Debug/hello -ex "b hello.h:7" Breakpoint 1 at 0x80484be: file ../src/hello.h, line 7. Working by first setting environment directory: > gdb.7.3 -q -batch /home/lmckhou/hello/Debug/hello -ex "dir /home/lmckhou/hello/src" -ex "b /home/lmckhou/hello/src/hello.h:7" Breakpoint 1 at 0x80484be: file ../src/hello.h, line 7. Working by starting the program first: > gdb.7.3 -q -batch /home/lmckhou/hello/Debug/hello -ex "start" -ex "b /home/lmckhou/hello/src/hello.h:7" Temporary breakpoint 1 at 0x804849d: file ../src/hello.cpp, line 6. Temporary breakpoint 1, main () at ../src/hello.cpp:6 6 int a = 0; Breakpoint 2 at 0x80484be: file ../src/hello.h, line 7.
Bug 225805 comment 55 proposes to use -env-dir just before setting a breakpoint, which could be a solution to this problem.
(In reply to comment #3) > Bug 225805 comment 55 proposes to use -env-dir just before setting a > breakpoint, which could be a solution to this problem. Sounds reasonable. So if setting the breakpoint fails and the file exists we should send the -env-dir and try again to set the breakpoint?
(In reply to comment #4) > (In reply to comment #3) > > Bug 225805 comment 55 proposes to use -env-dir just before setting a > > breakpoint, which could be a solution to this problem. > Sounds reasonable. So if setting the breakpoint fails and the file exists we > should send the -env-dir and try again to set the breakpoint? That is the idea, but it seems overkill because the problem we see only happens at startup. Maybe we can use this workaround only when initially setting breakpoints during launch time. But this will need to be tested with different GDB versions to see it works everywhere. I'm trying to understand why GDB behaves like this, to try to figure out the best way to deal with it.
