Re: Propose we release GDB 9.1 next weekend (Feb 01-02)

[Jonah Graham <jonah at kichwacoders dot com>]

On Sun, 26 Jan 2020 at 06:40, Joel Brobecker <brobecker@adacore.com> wrote:
>
> Pending comments, I will work on the GDB 9.1 release during
> the weekend of Feb 01-02.
>
>

Hi folks,

Sorry to be coming to the party a little late on this - but GDB 9.1
has a serious regression related to path handling. This affects
Eclipse CDT users because the default build system in CDT does not
pass absolute paths to GCC when compiling. Thanks to some efforts of
users who have been exposed early to this thanks to fc31 pushing
pre-releases of 9.1 out we have detected it before release, but just
barely :-)

The Bug is https://sourceware.org/bugzilla/show_bug.cgi?id=24915 and
it has been bouncing around for a while, with it seemingly fixed for a
while, but it turns out that there are lots of cases that it is not
fixed. The patch that causes the problem is
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a0c1ffedcf1988bc13fc5b6d57d3b74a17b60299

The summary is that GDB is often failing to insert breakpoints when
the absolute path to the file is passed to GDB if it was compiled with
a different path, such as a path with .. in the compilation path, or
symlinks. This would require IDEs to know the compilation path of a
file it has open when a breakpoint is inserted, rather than only
having to know the absolute path to the file that is actually open.

Setting basenames-may-differ to on is a workaround as the new code in
the commit is guarded by that. However GDB is failing even when
basenames don't differ.

I have added two short traces in Comment 17 with all the commands
(https://sourceware.org/bugzilla/show_bug.cgi?id=24915#c17), but I
want to show you the part of the trace that indicates this is a bug.
The breakpoint fails to insert on the first instance - but then works
on the second try with the intervening break with no path.

 $ /scratch/gdb/build-gdb-9/gdb/gdb --quiet main
Reading symbols from main...
(gdb) b /scratch/gdb/test/src/main2.c:1   ## Breakpoint fails here
No source file named /scratch/gdb/test/src/main2.c.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b main2.c:1
Breakpoint 1 at 0x609: file ../src/main2.c, line 2.
(gdb) b /scratch/gdb/test/src/main2.c:1  ## same command works here
Note: breakpoint 1 also set at pc 0x609.
Breakpoint 2 at 0x609: file ../src/main2.c, line 2.
(gdb) quit
 $

Sorry for bringing this up so late in the dev cycle - I thought this
was fixed, but it was only fixed for a limited number of cases.

Jonah