Bug 1750470

Cannot reopen the previous bug report, but the problem is
not corrected.

With gdb 7.6.1-114:

(gdb) b 15
No line 15 in the current file.
Make breakpoint pending on future shared library load? (y or [n])

With gdb 7.6.1-115:

(gdb) b 15
Breakpoint 1 at 0x4007dc: file bitmapSort.c, line 15.
(gdb) r
Starting program: /home/pcpa/bitmapSort 
Error in re-setting breakpoint 1: No source file named /home/pcpa/tmp/12345.

But as you can see, when actually reaching the breakpoint, it misbehaves.

The problem also happens at least on Fedora 30.

Moving to 7.9.

This upstream regression, while a regression, isn't important enough to be a blocker. Moving out to 7.9.

QE: Use test case in DESCRIPTION.

BEFORE (-116.el7):
$ gdb -q bitmapS
Reading symbols from /home/rhel7/rhbz/1750470/bitmapS...done.
(gdb) b 15
Breakpoint 1 at 0x4007ec: file bitmapS.c, line 15.
(gdb) r
Starting program: /home/rhel7/rhbz/1750470/bitmapS 
Error in re-setting breakpoint 1: No source file named /home/rhel7/rhbz/1750470/tmp/bitmapSort.c.
Made 26019726 comparisons, 8500000 assignments, 17000000 file writes, and 0 file reads
[Inferior 1 (process 3473) exited normally]
(gdb) 

AFTER (-117.el7):
$ gdb -q bitmapS
Reading symbols from /home/rhel7/rhbz/1750470/bitmapS...done.
(gdb) b 15
Breakpoint 1 at 0x4007ec: file bitmapS.c, line 15.
(gdb) r
Starting program: /home/rhel7/rhbz/1750470/bitmapS 

Breakpoint 1, main (argc=1, argv=0x7fffffffe038) at bitmapS.c:20
20		int             filewrites = 0;
(gdb)

I am going to need a new test cases for this. The one provided in the description is no longer sufficient.

  Updated testcase:

  Basically execute 'list' twice:

$ gdb bitmapS
...
(gdb) list
...
(gdb) list
...
(gdb) run
...
Error in re-setting breakpoint 1: No source file named /tmp/bitmapSort.c.
...

  The 'list' command causes it again to fail.

Ops, cut&paste problem, it is:

(gdb) list
(gdb) list
(gdb) b 15
(gdb) run

to reproduce the regression.

  There is still a problem.

  Reproducer:

$ mkdir foo,bar
$ cp bitmapSort.c foo,bar
$ gcc -O0 -g3 $PWD/foo,bar/bitmapSort.c -o bitmapS -lm
$ gdb bitmapS
(gdb) b 15
Breakpoint 1 at 0x4007ec: file .../foo,bar/bitmapSort.c, line 15.
(gdb) r
Starting program: .../bitmapS 
Error in re-setting breakpoint 1: Function ".../foo" not defined.
Made 26018941 comparisons, 8500000 assignments, 17000000 file writes, and 0 file reads
[Inferior 1 (process 2413) exited normally]

  Now they have a workaround with symbolic links, but previously commas
in paths did work.

(In reply to Paulo Andrade from comment #32)
> $ mkdir foo,bar
> $ cp bitmapSort.c foo,bar
> $ gcc -O0 -g3 $PWD/foo,bar/bitmapSort.c -o bitmapS -lm
> $ gdb bitmapS
> (gdb) b 15
> Breakpoint 1 at 0x4007ec: file .../foo,bar/bitmapSort.c, line 15.
> (gdb) r
> Starting program: .../bitmapS 
> Error in re-setting breakpoint 1: Function ".../foo" not defined.
> Made 26018941 comparisons, 8500000 assignments, 17000000 file writes, and 0
> file reads
> [Inferior 1 (process 2413) exited normally]

This is a new bug. If this must be fixed in gdb-7.6, please file a new bug
for it.

I have to ask, though: Why is DTS not an option?

That debugger is significantly newer than this RHEL 7 version, providing
much more maturity and new features.

>   Now they have a workaround with symbolic links, but previously commas
> in paths did work.

Because of 1777914, I've had to revert this patch. A team member has updated
tests for this bug, included in the -119 build, and he recommends using
"set basenames-may-differ on" option to resolve this original bug. [This
flag should also be set with the DTS gdb.]

  Previously (around the time the original bug report was opened) the user
tested devtoolset-7, and it did fail. Testing latest devtoolset-7 and the
problem still exist.
  User has been previously asked to test devtoolset-8, and has been asked
again, as latest devtoolset-8 works.

I see what's happened. I apologize: I'm testing DTS9 which has not yet
been released. Very sorry about that.

For the symlink bug, "set basenames-may-differ on" will need to be used for every
shipping version of GDB (RHEL 7+ and DTS 8+).

To be absolutely clear, does turning on  basenames-may-differ resolve
the customer's symlink issues?

I have tested the reported symlink test cases on
the (proposed) -119 build, DTS7.1, DTS8, and DTS9. All versions work with
"set basenames-may-differ on".

The reported comma-in-pathname problem (now 1779246) works on DTS8 and DTS9.
Only the RHEL7 system GDB fails this case. [But we'll move further discussion
about this problem to that bug.]

Verified against gdb-7.6.1-119.el7.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0993