[Bug gdb/25656] New: break $decimal gives breakpoint in other file with same name

[Bug gdb/25656] New: break $decimal gives breakpoint in other file with same name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25656

            Bug ID: 25656
           Summary: break $decimal gives breakpoint in other file with
                    same name
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case gdb.threads/execl.exp, with two executables: execl and
execl1.

And full package debug-info available, that is, on my openSUSE Leap 15.1
system, when starting the first executable:
...
$ gdb -batch execl -ex start
Temporary breakpoint 1 at 0x4006ee: file gdb.threads/execl.c, line 44.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdbc8) at
gdb.threads/execl.c:44
44        pthread_create (&thread1, NULL, thread_function, NULL);
...
no zypper debug-info installation hints are given.

And gdb build with configure flag --with-separate-debug-dir=/usr/lib/debug,
such that gdb can access the debug-info.

When running the test-case, we get this FAIL:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1 "execl" hit Breakpoint 2, __GI_execl (path=0x6024a0
"build/gdb/testsuite/outputs/gdb.threads/execl/execl1", arg=<optimized out>) at
execl.c:51^M
51        if (execl (new_image, new_image, NULL) == -1) /* set breakpoint here
*/^M
(gdb) FAIL: gdb.threads/execl.exp: continue across exec
...

The problem is earlier:
...
(gdb) break main^M
Breakpoint 1 at 0x4006ee: file gdb.threads/execl.c, line 44.^M
(gdb) run ^M
Starting program: build/gdb/testsuite/outputs/gdb.threads/execl/execl ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
Breakpoint 1, main (argc=1, argv=0x7fffffffd3f8) at gdb.threads/execl.c:44^M
44        pthread_create (&thread1, NULL, thread_function, NULL);^M
(gdb) b 51^M
Breakpoint 2 at 0x400787: gdb.threads/execl.c:51. (2 locations)^M
...

Adding a breakpoint info command, we can see which locations are involved:
...
(gdb) PASS: gdb.threads/execl.exp: set breakpoint at execl
info breakpoints^M
Num     Type           Disp Enb Address            What^M
1       breakpoint     keep y   0x00000000004006ee in main at \
  gdb.threads/execl.c:44^M
        breakpoint already hit 1 time^M
2       breakpoint     keep y   <MULTIPLE>         ^M
2.1                         y   0x0000000000400787 in main at \
  gdb.threads/execl.c:51^M
2.2                         y   0x00007ffff758d925 in __GI_execl at \
  execl.c:51^M
(gdb) PASS: gdb.threads/execl.exp: info breakpoints
...

So, the "b 51" command, executed while in main in file execl.c, gives us a
breakpoint in glibc's execl.c, at line 51.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25656] break $decimal gives breakpoint in other file with same name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25656

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/25656] break $decimal gives breakpoint in other file with same name

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25656

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
For "break LINE", I guess linespec should use the full path
of the current source file, to try to avoid this kind of thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.