GDB 9.1 release 2019-12-23 update

GDB 9.1 release 2019-12-23 update

[Joel Brobecker]

Hi everyone,

So, as far as I know, the only issues that are still open are
the issues that Eli found with the pre-release.

  - [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.

  - [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.

  - [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.

There might also be an issue with GDB/TUI, but that's less clear
at this stage.

Are there other issues that I may have missed for which we should
wait until we can release GDB 9.1?

Thank you!
-- 
Joel

Re: GDB 9.1 release 2019-12-23 update

[Eli Zaretskii]

> Date: Mon, 23 Dec 2019 13:30:31 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> 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.

>   - [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.

>   - [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.

>   - [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.

> 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?

Re: GDB 9.1 release 2019-12-23 update

[Eli Zaretskii]

> Date: Mon, 23 Dec 2019 16:13:47 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
> 
> >   - [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.

Done.

Re: GDB 9.1 release 2019-12-23 update

[Joel Brobecker]

> > 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.

-- 
Joel

Re: GDB 9.1 release 2019-12-23 update

[Andrew Burgess]

* 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

Re: GDB 9.1 release 2019-12-23 update

[Eli Zaretskii]

> Date: Tue, 24 Dec 2019 12:23:54 +0000
> From: Andrew Burgess <andrew.burgess@embecosm.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> 
> > > 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).

FTR, my GCC version is 8.3, and I did use -O2 optimizations.

Thanks.

Re: GDB 9.1 release 2019-12-23 update

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:

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

Andrew>   gdb::optional<ui_out_emit_list> asm_list;

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

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

You didn't miss anything.  This is just a bug in gcc (IMO).
There's a discussion here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635

Tom

Re: GDB 9.1 release 2019-12-23 update

[Eli Zaretskii]

> Date: Tue, 24 Dec 2019 07:46:52 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > >   - [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.

I added an attachment with the patch to the Bugzilla report, it should
appear shortly on the bug-binutils mailing list.  Let's see what
happens next.

Re: GDB 9.1 release 2019-12-23 update

[Christian Biesinger via gdb-patches]

On Tue, Dec 24, 2019 at 5:21 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Tue, 24 Dec 2019 07:46:52 +0400
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: gdb-patches@sourceware.org
> >
> > > >   - [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.
>
> I added an attachment with the patch to the Bugzilla report, it should
> appear shortly on the bug-binutils mailing list.  Let's see what
> happens next.

I don't know how binutils works, but if they work like gdb, it may be
worth sending the patch to the binutils mailing list directly instead
of relying on people to read bug-binutils?

Christian

Re: GDB 9.1 release 2019-12-23 update

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Thu, 26 Dec 2019 23:39:36 +0100
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> > I added an attachment with the patch to the Bugzilla report, it should
> > appear shortly on the bug-binutils mailing list.  Let's see what
> > happens next.
> 
> I don't know how binutils works, but if they work like gdb, it may be
> worth sending the patch to the binutils mailing list directly instead
> of relying on people to read bug-binutils?

I'm fine with that, but if they don't read bug-binutils, then why does
that list even exist?

I actually suggest that Joel or Pedro post to the binutils mailing
list quoting the Bugzilla report and/or the bug-binutils messages

  https://lists.gnu.org/archive/html/bug-binutils/2019-11/msg00006.html
  https://lists.gnu.org/archive/html/bug-binutils/2019-12/msg00162.html

and telling the Binutils folks that this currently blocks a GDB
release.  I think this would have a much more profound effect than me
doing the same.

Or we could make the release regardless of the libctf issues with
MinGW.

Re: GDB 9.1 release 2019-12-23 update

[Andrew Burgess]

* Joel Brobecker <brobecker@adacore.com> [2019-12-23 13:30:31 +0400]:

> Are there other issues that I may have missed for which we should
> wait until we can release GDB 9.1?

We might want to consider waiting for a fix for this issue:

  https://sourceware.org/ml/gdb-patches/2019-12/msg01007.html

If nobody else beats me to it then I'll get a fix for this in the next
couple of days.

Thanks,
Andrew

Re: GDB 9.1 release 2019-12-23 update

[Joel Brobecker]

Hi Andrew,

> We might want to consider waiting for a fix for this issue:
> 
>   https://sourceware.org/ml/gdb-patches/2019-12/msg01007.html
> 
> If nobody else beats me to it then I'll get a fix for this in the next
> couple of days.

Thanks for the heads up on that one. I agree we should wait for it
to be fixed before we release. I'm adding it to the list!

-- 
Joel

Re: GDB 9.1 release 2019-12-23 update

[Andrew Burgess]

* Joel Brobecker <brobecker@adacore.com> [2020-01-02 14:56:45 +0400]:

> Hi Andrew,
> 
> > We might want to consider waiting for a fix for this issue:
> > 
> >   https://sourceware.org/ml/gdb-patches/2019-12/msg01007.html
> > 
> > If nobody else beats me to it then I'll get a fix for this in the next
> > couple of days.
> 
> Thanks for the heads up on that one. I agree we should wait for it
> to be fixed before we release. I'm adding it to the list!

I pushed the fix for this issue to master and gdb-9-branch.

Thanks,
Andrew

Re: GDB 9.1 release 2019-12-23 update

[Hannes Domani via gdb-patches]

 Am Montag, 23. Dezember 2019, 10:30:53 MEZ hat Joel Brobecker <brobecker@adacore.com> Folgendes geschrieben:

> Are there other issues that I may have missed for which we should
> wait until we can release GDB 9.1?

What about the patch to disable _FORTIFY_SOURCE on mingw?:
https://sourceware.org/ml/gdb-patches/2019-12/msg00787.html

Otherwise you can't use a recent mingw-w64-gcc to build gdb at all.