Re: GDB 9.1 release 2019-12-23 update

Andrew Burgess
2019-12-24T12:24:01Z

* Joel Brobecker <brobecker@adacore.com> [2019-12-24 07:46:52 +0400]:

> > > So, as far as I know, the only issues that are still open are
> > > the issues that Eli found with the pre-release.
> >
> > Sorry about that.
>
> Not your fault!
>
> > > - [EliZ] readline/colors.c build failure
> > >
> > > Caused by S_IXGRP and S_IXOTH not being defined on MinGW.
> > > Patch sent to readline, and should be applied to our local
> > > tree soon.
> >
> > Will do soon.
>
> Nice.
>
> > > - [EliZ] configure warning when checking for pthread-config
> > >
> > > Problem understood, but EliZ blocked because he doesn't have
> > > the correct auto-tools version. Hopefully building those
> > > from source is an option.
> >
> > I believe this was already fixed.
>
> Double Nice.
>
> > > - [Eliz] libtcf fails to build on MinGW
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=25155
> > >
> > > Problem reported to binutils on Dec 17th, but so far
> > > no answer as far as I can tell.
> > > https://sourceware.org/ml/binutils/2019-12/msg00277.html
> > >
> > > If we don't get an answer after the end of year holidays,
> > > I suggest we send in a patch, which will likely help move
> > > things along. From Eli's message on bugzilla, we shouldn't
> > > be far from having one.
> >
> > I already have a patch, so I can apply it whenever you say so.
>
> Let's try to have it reviewed by the binutils folks if we can.
> It seems relatively straightforward, but I tend to avoid fixing
> things in a branch before it gets fixed in master. Maybe send
> the patch to binutils with an RFA? If that doesn't work, then
> we'll consider the option of just patching our branch so
> we can release.
>
> > > Are there other issues that I may have missed for which we should
> > > wait until we can release GDB 9.1?
> >
> > What about the compilation warning in record-btrace.c I reported in
> > https://sourceware.org/ml/gdb-patches/2019-12/msg00706.html? Do we
> > want to fix it?
>
> We can, but (IMO) not super critical. FWIW, I don't get the warning
> when buidling on GNU/Linux.

I can reproduce the warning on GNU/Linux, but it only crops up at some
optimisation levels, -O0 doesn't warn for me, while -O1 and -O2 do.
I've tested with GCC 8.3, 9.2, and a 10.??. This is all on a Fedora
27 system (yes, I really should update).

That said, I had a look at the code in question and I suspect the
warning is incorrect, unless I'm missing some clever C++ corner case,
which is quite possible. So, we have one of these:

gdb::optional<ui_out_emit_list> asm_list;

The "uninitialised" variable is a member of the ui_out_emit_list,
being used during its destructor. But the destructor is only called
if the ui_out_emit_list is initialised, which requires the member
variable to be set....

Currently I would be happy to release with the warning present.

Thanks,
Andrew