GDB 8.2.1 release -- 2018-11-06 status update

[Joel Brobecker]

Hello everyone,

Hard to believe it, but it's been 2 months already since we released
8.2. So, time to think about the 8.2.1 release, if we want to target
Dec 5th as our release date.

So far, we have the following changes in 8.2.1:

* PR build/23516 (gdb build error under msys+mingw: strip can't handle gdb-add-index.exe)
* PR build/23623 (install-strip fails)
* PR rust/23626 (gdb crashes in upstream rust nil-enum test)
* PR rust/23650 (rust field name access error mentions "foo")
* PR python/23669 (gdb.execute("show commands") doesn't work)

We have the following PRs open with the target milestone set to 8.2.1:

* [*UNASSIGNED*] PR gdb/23663
gdb 8.1.1: undefined rpl_stat function with musl toolchains
https://sourceware.org/bugzilla/show_bug.cgi?id=23663

As far as I can tell, this one can be closed, now, thanks
to the following patch from Sergio:
- master: 3c025cfe5efc44eb4dfb03b53dca28e75096dd1e
- gdb-8.2-branch: 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be

Author: Sergio Durigan Junior <***@redhat.com>
Subject: Move 'is_regular_file' from common-utils.c to filestuff.c

* [*UNASSIGNED*] PR gdb/23838
8.2 regression for invalid -data-directory
https://sourceware.org/bugzilla/show_bug.cgi?id=23838

Caused by [PATCH 01/40] Convert struct target_ops to C++] it seems.
It doesn't look very difficult to look into it; it just needs
a volunteer. Otherwise, it is likely that no progress will be
made towards a fix.

Note that there is a simple workaround, since the problem appears
limited to passing a file as a datadir, which is of course invalid.
So while not super elegant, I wouldn't consider this blocking
either.

Any other issues we should be considering? If yes, please let us know
here. I we agree that an issue is blocking for 8.2.1, then we'll need
a PR number describing the issue, and mark that PR with the 8.2.1 as
the target milestone.

Thank you!

[Sergio Durigan Junior]

Post by Joel Brobecker
Hello everyone,

Hi, Joel!

First of all, thanks a lot for taking care of this release (again).

[...]

Post by Joel Brobecker
* [*UNASSIGNED*] PR gdb/23663
gdb 8.1.1: undefined rpl_stat function with musl toolchains
https://sourceware.org/bugzilla/show_bug.cgi?id=23663
As far as I can tell, this one can be closed, now, thanks
- master: 3c025cfe5efc44eb4dfb03b53dca28e75096dd1e
- gdb-8.2-branch: 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be
Subject: Move 'is_regular_file' from common-utils.c to filestuff.c

True, this should be fixed by the commit you mentioned. Should I go
ahead and close the PR, then?

Thanks,

[Joel Brobecker]

Post by Sergio Durigan Junior

Post by Joel Brobecker
* [*UNASSIGNED*] PR gdb/23663
gdb 8.1.1: undefined rpl_stat function with musl toolchains
https://sourceware.org/bugzilla/show_bug.cgi?id=23663
As far as I can tell, this one can be closed, now, thanks
- master: 3c025cfe5efc44eb4dfb03b53dca28e75096dd1e
- gdb-8.2-branch: 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be
Subject: Move 'is_regular_file' from common-utils.c to filestuff.c

True, this should be fixed by the commit you mentioned. Should I go
ahead and close the PR, then?

Thanks for confirming Sergio. I closed the PR.

[Sergio Durigan Junior]

Post by Joel Brobecker

Post by Sergio Durigan Junior

Post by Joel Brobecker
* [*UNASSIGNED*] PR gdb/23663
gdb 8.1.1: undefined rpl_stat function with musl toolchains
https://sourceware.org/bugzilla/show_bug.cgi?id=23663
As far as I can tell, this one can be closed, now, thanks
- master: 3c025cfe5efc44eb4dfb03b53dca28e75096dd1e
- gdb-8.2-branch: 5de69bdbd0bbd7941b4cd93d4571f5e22cdb28be
Subject: Move 'is_regular_file' from common-utils.c to filestuff.c

True, this should be fixed by the commit you mentioned. Should I go
ahead and close the PR, then?

Thanks for confirming Sergio. I closed the PR.

Thanks, Joel.

[Keith Seitz]

Post by Joel Brobecker
Any other issues we should be considering? If yes, please let us know
here. I we agree that an issue is blocking for 8.2.1, then we'll need
a PR number describing the issue, and mark that PR with the 8.2.1 as
the target milestone.

I would like to propose the following two bugs for inclusion in the point
release. These are related to symtab/23010 (DICT_LANGUAGE != SYMBOL_LANGUAGE
assertion).

Keith

* gdb/23712 (dw2_add_symbol_to_list language assertion)

We thought 23010 was fixed. To catch it more easily, the assertion reported
in 23712 was added. The underlying problem is compilations with LTO. GCC
introduces an artificial compile unit with language C99 which imports DIEs
of language C++, triggering the assertions.

I have had a patch for this for weeks, but I am only now running through buildbot.
While I have done extensive regression and performance testing with it (against
firefox), it is by no means a trivial patch. Maintainers will have to
usability against the risk offered by including an "unproven" patch.

* unfiled gdb bug (mentioned in 23010)

There was also a related 23010 fix to xcoffread.c that might warrant inclusion.
I have only tested that the commit applies. I haven't tested it yet.

commit b971899198607b844f5a37e39dc561766c3b331a
Author: Sangamesh Mallayya <***@in.ibm.com>
Date: Fri Oct 26 15:31:36 2018 +0530

Fix SYMBOL_LANGUAGE assertion failure on AIX.

[Sergio Durigan Junior]

Post by Keith Seitz

Post by Joel Brobecker
Any other issues we should be considering? If yes, please let us know
here. I we agree that an issue is blocking for 8.2.1, then we'll need
a PR number describing the issue, and mark that PR with the 8.2.1 as
the target milestone.

I would like to propose the following two bugs for inclusion in the point
release. These are related to symtab/23010 (DICT_LANGUAGE != SYMBOL_LANGUAGE
assertion).
Keith
* gdb/23712 (dw2_add_symbol_to_list language assertion)
We thought 23010 was fixed. To catch it more easily, the assertion reported
in 23712 was added. The underlying problem is compilations with LTO. GCC
introduces an artificial compile unit with language C99 which imports DIEs
of language C++, triggering the assertions.
I have had a patch for this for weeks, but I am only now running through buildbot.
While I have done extensive regression and performance testing with it (against
firefox), it is by no means a trivial patch. Maintainers will have to
usability against the risk offered by including an "unproven" patch.

We also have a Fedora GDB bug report (and a bunch of dups) for this
problem:

https://bugzilla.redhat.com/show_bug.cgi?id=1560010
https://bugzilla.redhat.com/show_bug.cgi?id=1638798

I've been following Keith's efforts to fix this for a while now, and I
agree it's a good idea to include this one as a blocker for the 8.2.1
release.

Thanks,

[Joel Brobecker]

Hi Keith,

Thanks for jumping in!

Post by Keith Seitz
* gdb/23712 (dw2_add_symbol_to_list language assertion)
We thought 23010 was fixed. To catch it more easily, the assertion reported
in 23712 was added. The underlying problem is compilations with LTO. GCC
introduces an artificial compile unit with language C99 which imports DIEs
of language C++, triggering the assertions.
I have had a patch for this for weeks, but I am only now running through buildbot.
While I have done extensive regression and performance testing with it (against
firefox), it is by no means a trivial patch. Maintainers will have to
usability against the risk offered by including an "unproven" patch.

I've marked it for 8.2.1 to start. But what you are saying does not
sound good at all :-/, especially for a .1 release. Let's get the patch
in master to start, and go from there.

Post by Keith Seitz
* unfiled gdb bug (mentioned in 23010)
There was also a related 23010 fix to xcoffread.c that might warrant
inclusion. I have only tested that the commit applies. I haven't
tested it yet.
commit b971899198607b844f5a37e39dc561766c3b331a
Date: Fri Oct 26 15:31:36 2018 +0530
Fix SYMBOL_LANGUAGE assertion failure on AIX.

No problem for me backporting this patch with a yet-to-be-created PR.