The test case has two .c files, f.c and foo/f.c, and compile them as follows, 1. compile foo/f.c to shared lib, $ gcc -g -c -Wall -Werror -fpic f.c $ gcc -g -shared -o libf.so f.o 2. compile f.c to an executable, which needs libf.so, $ gcc -Wall -L/tmp/bar/foo -o f.exe -g f.c -lf 3. rename directory foo to bar, $ mv foo/ bar 4. Set LD_LIBRARY_PATH=$PWD/bar:$LD_LIBRARY_PATH, and start gdb with f.exe, (gdb) b main Breakpoint 1 at 0x40069f: file f.c, line 6. (gdb) run Starting program: /tmp/bar/f.exe Breakpoint 1, main () at f.c:6 6 return foo () + bar_in_main (); (gdb) b 12 Breakpoint 2 at 0x4006b8: /tmp/bar/f.c:12. (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x000000000040069f in main at f.c:6 breakpoint already hit 1 time 2 breakpoint keep y <MULTIPLE> 2.1 y 0x00000000004006b8 in bar_in_main at f.c:12 2.2 y 0x00007ffff7bd869f in bar_in_solib at f.c:12 "b 12" should set breakpoint on line 12 of current source file, so breakpoint 2.1 is expected,but breakpoint 2.2 isn't.
test case, $ cat f.c extern int foo (void); static int bar_in_main (void); int main (void) { return foo () + bar_in_main (); } static int bar_in_main (void) { return 0; } $ cat foo/f.c static int bar_in_solib (void); int foo (void) { return bar_in_solib (); } static int bar_in_solib (void) { return 0; }
The test case is derived from https://www.sourceware.org/ml/gdb-patches/2015-12/msg00321.html
There are more cases we need to think about, and I assume gdb doc is correct, 1. "f.c:12", according to linespec doc, "Specifies the line linenum in the source file filename. If filename is a relative file name, then it will match any source file name with the same trailing components." (gdb) b f.c:12 Breakpoint 5 at 0x4006b8: f.c:12. (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 5 breakpoint keep y <MULTIPLE> 5.1 y 0x00000000004006b8 in bar_in_main at f.c:12 5.2 y 0x00007ffff7bd869f in bar_in_solib at f.c:12 GDB is correct. 2. "/tmp/bar/f.c:12" (gdb) b /tmp/bar/f.c:12 Breakpoint 6 at 0x4006b8: /tmp/bar/f.c:12. (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 6 breakpoint keep y <MULTIPLE> 6.1 y 0x00000000004006b8 in bar_in_main at f.c:12 6.2 y 0x00007ffff7bd869f in bar_in_solib at f.c:12 GDB is incorrect. 3. "-source f.c -line 12", as gdb doc "explicit location" says, "The value specifies the source file name. To differentiate between files with the same base name, prepend as many directories as is necessary to uniquely identify the desired file, e.g., foo/bar/baz.c. Otherwise gdb will use the first file it finds with the given base name.", so GDB should set one breakpoint location, (gdb) break -source f.c -line 12 Breakpoint 7 at 0x4006b8: -source f.c -line 12. (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 7 breakpoint keep y <MULTIPLE> 7.1 y 0x00000000004006b8 in bar_in_main at f.c:12 7.2 y 0x00007ffff7bd869f in bar_in_solib at f.c:12 GDB is incorrect.
> 3. "-source f.c -line 12", as gdb doc "explicit location" says, "The value > specifies the source file name. To differentiate between files with the same > base name, prepend as many directories as is necessary to uniquely identify > the desired file, e.g., foo/bar/baz.c. Otherwise gdb will use the first file > it finds with the given base name.", so GDB should set one breakpoint > location, > > (gdb) break -source f.c -line 12 > Breakpoint 7 at 0x4006b8: -source f.c -line 12. (2 locations) > (gdb) info breakpoints > Num Type Disp Enb Address What > 7 breakpoint keep y <MULTIPLE> > 7.1 y 0x00000000004006b8 in bar_in_main at f.c:12 > 7.2 y 0x00007ffff7bd869f in bar_in_solib at > f.c:12 > > GDB is incorrect. I'd say this one is correct. Both files are named "f.c", so the -source specified failed to "prepend as many directories as is necessary to uniquely identify the desired file". I wouldn't say that "Otherwise gdb will use the first file it finds with the given base name." is desirable, as it's brittle, depends on which symtab gdb happens to expand first. I think in that case, it's the docs that should be updated.
Per sub-discussion around https://sourceware.org/ml/gdb-patches/2016-02/msg00104.html, this is not a regression, so removing 7.11 milestone.
(In reply to Pedro Alves from comment #4) > > 3. "-source f.c -line 12", as gdb doc "explicit location" says, "The value > > specifies the source file name. To differentiate between files with the same > > base name, prepend as many directories as is necessary to uniquely identify > > the desired file, e.g., foo/bar/baz.c. Otherwise gdb will use the first file > > it finds with the given base name.", so GDB should set one breakpoint > > location, > > > > (gdb) break -source f.c -line 12 > > Breakpoint 7 at 0x4006b8: -source f.c -line 12. (2 locations) > > (gdb) info breakpoints > > Num Type Disp Enb Address What > > 7 breakpoint keep y <MULTIPLE> > > 7.1 y 0x00000000004006b8 in bar_in_main at f.c:12 > > 7.2 y 0x00007ffff7bd869f in bar_in_solib at > > f.c:12 > > > > GDB is incorrect. > > I'd say this one is correct. > > Both files are named "f.c", so the -source specified failed to "prepend as > many directories as is necessary to uniquely identify the desired file". > > I wouldn't say that "Otherwise gdb will use the first file it finds with the > given base name." is desirable, as it's brittle, depends on which symtab gdb > happens to expand first. I think in that case, it's the docs that should be > updated. Yes, it is hard to define "first" from user's perspective. I agree we need to update doc to match current GDB behaviour. I'll do that.