GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Joel Brobecker]

Hello everyone,

Thanks again to everyone who's been helping on this release so far.
See the summary below, where we only have 2 patches left to backport.

Unless there are any issues that we're discovering last minute,
I propose we create the release sometime next weekend:

    13-14 March

Cheers!

Fixed Since the Previous Update:
--------------------------------

  * [<Simon + Andrew>] <PR backtrace/27147>
    [GNU/Linux, sparc64] GDB is unable to print full stack trace (got "previous frame inner to this frame" errors)
    https://sourceware.org/bugzilla/show_bug.cgi?id=27147

  * [KeithS] <PR gdb/27333>
    [dwarf-5] abort on unhandled DW_TAG_type_unit in process_psymtab_comp_unit
    https://sourceware.org/bugzilla/show_bug.cgi?id=27333

Added Since the Last Update:
----------------------------

  * [KevinB] <**PR MISSING**>
    Fix aarch64-linux-hw-point.c build problem with glibc-2.33
    https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c

        Already in master. Needs a PR to be created, before the patches
        can be backported.

  * [KevinB] <**PR MISSING**>
    amd64-linux-siginfo.c: Adjust include order to avoid gnulib error
    https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116

        Already in master. Needs a PR to be created, before the patches
        can be backported.

Other Ongoing Items:
--------------------

  < none :) >

Not Critical, but Requested:
----------------------------

  < none :) >

Thank you!
-- 
Joel

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Kevin Buettner]

On Sat, 6 Mar 2021 10:46:11 +0400
Joel Brobecker <brobecker@adacore.com> wrote:

> Added Since the Last Update:
> ----------------------------
> 
>   * [KevinB] <**PR MISSING**>
>     Fix aarch64-linux-hw-point.c build problem with glibc-2.33
>     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c
> 
>         Already in master. Needs a PR to be created, before the patches
>         can be backported.
> 
>   * [KevinB] <**PR MISSING**>
>     amd64-linux-siginfo.c: Adjust include order to avoid gnulib error
>     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116
> 
>         Already in master. Needs a PR to be created, before the patches
>         can be backported.

The PR numbers for these are 27536 and 27535, respectively.

I cherry-picked them to gdb-10-branch, updating ChangeLog and the
commit logs to include the bug numbers.  I've pushed those changes to
the branch.

Kevin

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Joel Brobecker]

> > Added Since the Last Update:
> > ----------------------------
> > 
> >   * [KevinB] <**PR MISSING**>
> >     Fix aarch64-linux-hw-point.c build problem with glibc-2.33
> >     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c
> > 
> >         Already in master. Needs a PR to be created, before the patches
> >         can be backported.
> > 
> >   * [KevinB] <**PR MISSING**>
> >     amd64-linux-siginfo.c: Adjust include order to avoid gnulib error
> >     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116
> > 
> >         Already in master. Needs a PR to be created, before the patches
> >         can be backported.
> 
> The PR numbers for these are 27536 and 27535, respectively.
> 
> I cherry-picked them to gdb-10-branch, updating ChangeLog and the
> commit logs to include the bug numbers.  I've pushed those changes to
> the branch.

Thanks for doing all of the above and the note, Kevin.

I've set the target milestone to 10.2 for those, so my scripts can
find them when I announce the release; unless there is more you want
to do for these PRs, I think we can close them now.

-- 
Joel

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Kevin Buettner]

On Sun, 7 Mar 2021 09:45:32 +0400
Joel Brobecker <brobecker@adacore.com> wrote:

> > > Added Since the Last Update:
> > > ----------------------------
> > > 
> > >   * [KevinB] <**PR MISSING**>
> > >     Fix aarch64-linux-hw-point.c build problem with glibc-2.33
> > >     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c
> > > 
> > >         Already in master. Needs a PR to be created, before the patches
> > >         can be backported.
> > > 
> > >   * [KevinB] <**PR MISSING**>
> > >     amd64-linux-siginfo.c: Adjust include order to avoid gnulib error
> > >     https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116
> > > 
> > >         Already in master. Needs a PR to be created, before the patches
> > >         can be backported.  
> > 
> > The PR numbers for these are 27536 and 27535, respectively.
> > 
> > I cherry-picked them to gdb-10-branch, updating ChangeLog and the
> > commit logs to include the bug numbers.  I've pushed those changes to
> > the branch.  
> 
> Thanks for doing all of the above and the note, Kevin.
> 
> I've set the target milestone to 10.2 for those, so my scripts can
> find them when I announce the release; unless there is more you want
> to do for these PRs, I think we can close them now.

I've closed them.

Kevin

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Simon Marchi]

On 2021-03-06 1:46 a.m., Joel Brobecker wrote:
> Hello everyone,
> 
> Thanks again to everyone who's been helping on this release so far.
> See the summary below, where we only have 2 patches left to backport.
> 
> Unless there are any issues that we're discovering last minute,
> I propose we create the release sometime next weekend:
> 
>      13-14 March
> 
> Cheers!
> 
> Fixed Since the Previous Update:
> --------------------------------
> 
>    * [<Simon + Andrew>] <PR backtrace/27147>
>      [GNU/Linux, sparc64] GDB is unable to print full stack trace (got "previous frame inner to this frame" errors)
>      https://sourceware.org/bugzilla/show_bug.cgi?id=27147
> 
>    * [KeithS] <PR gdb/27333>
>      [dwarf-5] abort on unhandled DW_TAG_type_unit in process_psymtab_comp_unit
>      https://sourceware.org/bugzilla/show_bug.cgi?id=27333
> 
> Added Since the Last Update:
> ----------------------------
> 
>    * [KevinB] <**PR MISSING**>
>      Fix aarch64-linux-hw-point.c build problem with glibc-2.33
>      https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=665af52ec2a52184d39a76d6e724fa4733dbab3c
> 
>          Already in master. Needs a PR to be created, before the patches
>          can be backported.
> 
>    * [KevinB] <**PR MISSING**>
>      amd64-linux-siginfo.c: Adjust include order to avoid gnulib error
>      https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8488c357ce4fc309d49c7b0224cf9574b68e8116
> 
>          Already in master. Needs a PR to be created, before the patches
>          can be backported.
> 
> Other Ongoing Items:
> --------------------
> 
>    < none :) >
> 
> Not Critical, but Requested:
> ----------------------------
> 
>    < none :) >
> 
> Thank you!
> 

A new issue has popped up:

   https://sourceware.org/bugzilla/show_bug.cgi?id=27541

Tom Tromey and I would be good candidates to look a it,
because it's related to the DWARF symbol sharing, which
we've both worked on.  I will try to give it a look in
the following days.

Simon

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Joel Brobecker]

Hi Simon,

> A new issue has popped up:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=27541
> 
> Tom Tromey and I would be good candidates to look a it,
> because it's related to the DWARF symbol sharing, which
> we've both worked on.  I will try to give it a look in
> the following days.

Thanks for the heads up, Simon. I've changed its Target Mileston
to 10.2 in Bugzilla.

-- 
Joel

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Simon Marchi]

On 2021-03-09 9:48 p.m., Joel Brobecker wrote:
> Hi Simon,
> 
>> A new issue has popped up:
>>
>>   https://sourceware.org/bugzilla/show_bug.cgi?id=27541
>>
>> Tom Tromey and I would be good candidates to look a it,
>> because it's related to the DWARF symbol sharing, which
>> we've both worked on.  I will try to give it a look in
>> the following days.
> 
> Thanks for the heads up, Simon. I've changed its Target Mileston
> to 10.2 in Bugzilla.
> 

I've been looking at this on and off for the last few days, and I don't
think I'll be able to come up with a proper fix in a short time frame.
And even if I did, I think it would be too risky for merging in a stable
branch right before releasing.

The alternative I see to unblock the release is to disable the sharing of
partial symbols between objfiles for now.  Essentially, a patch that does

    diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
    index 704ba9f36655..5d9256bece1e 100644
    --- a/gdb/dwarf2/read.c
    +++ b/gdb/dwarf2/read.c
    @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
             doesn't require relocations and if there aren't partial symbols
             from some other reader.  */
           if (!objfile_has_partial_symbols (objfile)
    -         && !gdb_bfd_requires_relocations (objfile->obfd))
    +         && !gdb_bfd_requires_relocations (objfile->obfd)
    +         && 0)
            {
              /* See if one has been created for this BFD yet.  */
              per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);

We can then take our time to look at a proper fix for master.

Simon

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Joel Brobecker]

Hi Simon,

> >> Tom Tromey and I would be good candidates to look a it,
> >> because it's related to the DWARF symbol sharing, which
> >> we've both worked on.  I will try to give it a look in
> >> the following days.
> > 
> > Thanks for the heads up, Simon. I've changed its Target Mileston
> > to 10.2 in Bugzilla.
> > 
> 
> I've been looking at this on and off for the last few days, and I don't
> think I'll be able to come up with a proper fix in a short time frame.
> And even if I did, I think it would be too risky for merging in a stable
> branch right before releasing.

That's what I was fearing already, when I saw the PR and the discussions
that were logged so far.

> The alternative I see to unblock the release is to disable the sharing of
> partial symbols between objfiles for now.  Essentially, a patch that does
> 
>     diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>     index 704ba9f36655..5d9256bece1e 100644
>     --- a/gdb/dwarf2/read.c
>     +++ b/gdb/dwarf2/read.c
>     @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
>              doesn't require relocations and if there aren't partial symbols
>              from some other reader.  */
>            if (!objfile_has_partial_symbols (objfile)
>     -         && !gdb_bfd_requires_relocations (objfile->obfd))
>     +         && !gdb_bfd_requires_relocations (objfile->obfd)
>     +         && 0)
>             {
>               /* See if one has been created for this BFD yet.  */
>               per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);
> 
> We can then take our time to look at a proper fix for master.

It's quite nice to see that this feature could be disabled with
a one-liner like this.

Unless Tom has other ideas, this seems like the way to go for me.

I also wanted to mention that, in terms of timing, I was planning
on starting the regular updates for the 11.1 releases pretty much
right after the GDB 10.2 is out. We will just have to list this one
right from the beginning.

Procedurally speaking, what would help is if we close the PR about
the crash with the target milestone set to 10.2 right after your patch
is in, and then re-open the PR about the partial symtab sharing to
fix the crash on master (or open a new one if there wasn't one
already). That way, anyone asking for the list of fixes from 10.1
to 10.2 would find this issue (this is something I do when publishing
a .2, for instance).

Thanks Simon!
-- 
Joel

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Tom Tromey]

>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>> index 704ba9f36655..5d9256bece1e 100644
>> --- a/gdb/dwarf2/read.c
>> +++ b/gdb/dwarf2/read.c
>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
>> doesn't require relocations and if there aren't partial symbols
>> from some other reader.  */
>> if (!objfile_has_partial_symbols (objfile)
>> -         && !gdb_bfd_requires_relocations (objfile->obfd))
>> +         && !gdb_bfd_requires_relocations (objfile->obfd)
>> +         && 0)
>> {
>> /* See if one has been created for this BFD yet.  */
>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);
>> 
>> We can then take our time to look at a proper fix for master.

Joel> It's quite nice to see that this feature could be disabled with
Joel> a one-liner like this.

Joel> Unless Tom has other ideas, this seems like the way to go for me.

Sorry I didn't respond to this earlier.
I think it's fine for the branch.

I came up with a complicated plan for the trunk, but after some
reflection, I think a better plan is to notice OBJF_READNOW and refuse
to do any sharing in this case.  That is, it's your patch, but replacing
"0" with a check of OBJF_READNOW.  The appended probably has the wrong
line numbers but it shows the idea.

This -readnow stuff is an optimization, which in retrospect is kind of
silly, because on the whole I'd rather people not use -readnow anyway,
so why bother optimizing.  But when I added the gdb-index code, I
noticed the possibility and I guess I couldn't resist.

Tom

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 11cdcd02d0a..ec044ab66e5 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile,
     {
       dwarf2_per_bfd *per_bfd;
 
-      /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD
-	 doesn't require relocations.  */
-      if (!gdb_bfd_requires_relocations (objfile->obfd))
+      /* We can share a "dwarf2_per_bfd" with other objfiles if the
+	 BFD doesn't require relocations, and if -readnow was never
+	 requested.  */
+      if (!gdb_bfd_requires_relocations (objfile->obfd)
+	  && (objfile->flags & OBJF_READNOW) == 0)
 	{
 	  /* See if one has been created for this BFD yet.  */
 	  per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Joel Brobecker]

Hi Tom,

On Mon, Mar 29, 2021 at 11:02:13PM -0600, Tom Tromey wrote:
> >> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> >> index 704ba9f36655..5d9256bece1e 100644
> >> --- a/gdb/dwarf2/read.c
> >> +++ b/gdb/dwarf2/read.c
> >> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
> >> doesn't require relocations and if there aren't partial symbols
> >> from some other reader.  */
> >> if (!objfile_has_partial_symbols (objfile)
> >> -         && !gdb_bfd_requires_relocations (objfile->obfd))
> >> +         && !gdb_bfd_requires_relocations (objfile->obfd)
> >> +         && 0)
> >> {
> >> /* See if one has been created for this BFD yet.  */
> >> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);
> >> 
> >> We can then take our time to look at a proper fix for master.
> 
> Joel> It's quite nice to see that this feature could be disabled with
> Joel> a one-liner like this.
> 
> Joel> Unless Tom has other ideas, this seems like the way to go for me.
> 
> Sorry I didn't respond to this earlier.
> I think it's fine for the branch.

Great, thank you!

Speaking of the branch, given your patch below, perhaps we can have
best of both worlds if we go with the solution you suggest?
If we could converge on that by the time the weekend comes,
I think it would be reasonable to backport your patch to the branch
as well.

> I came up with a complicated plan for the trunk, but after some
> reflection, I think a better plan is to notice OBJF_READNOW and refuse
> to do any sharing in this case.  That is, it's your patch, but replacing
> "0" with a check of OBJF_READNOW.  The appended probably has the wrong
> line numbers but it shows the idea.
> 
> This -readnow stuff is an optimization, which in retrospect is kind of
> silly, because on the whole I'd rather people not use -readnow anyway,

Same here.

> so why bother optimizing.  But when I added the gdb-index code, I
> noticed the possibility and I guess I couldn't resist.

Lol.

> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 11cdcd02d0a..ec044ab66e5 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile,
>      {
>        dwarf2_per_bfd *per_bfd;
>  
> -      /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD
> -	 doesn't require relocations.  */
> -      if (!gdb_bfd_requires_relocations (objfile->obfd))
> +      /* We can share a "dwarf2_per_bfd" with other objfiles if the
> +	 BFD doesn't require relocations, and if -readnow was never
> +	 requested.  */
> +      if (!gdb_bfd_requires_relocations (objfile->obfd)
> +	  && (objfile->flags & OBJF_READNOW) == 0)
>  	{
>  	  /* See if one has been created for this BFD yet.  */
>  	  per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);

Sounds like a good idea, especially if that avoids a complicated
plan to make it work.

The only small comment I have is that it would be useful, I think,
to explain why we say we cannot share the dwarf2_per_bfd when -readnow
is in effect (too complicated to support and not worth the effort
considering that performance is typically not as important in
the case of -readnow).

-- 
Joel

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Simon Marchi]

On 2021-03-30 1:02 a.m., Tom Tromey wrote:
>>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>>> index 704ba9f36655..5d9256bece1e 100644
>>> --- a/gdb/dwarf2/read.c
>>> +++ b/gdb/dwarf2/read.c
>>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
>>> doesn't require relocations and if there aren't partial symbols
>>> from some other reader.  */
>>> if (!objfile_has_partial_symbols (objfile)
>>> -         && !gdb_bfd_requires_relocations (objfile->obfd))
>>> +         && !gdb_bfd_requires_relocations (objfile->obfd)
>>> +         && 0)
>>> {
>>> /* See if one has been created for this BFD yet.  */
>>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);
>>>
>>> We can then take our time to look at a proper fix for master.
> 
> Joel> It's quite nice to see that this feature could be disabled with
> Joel> a one-liner like this.
> 
> Joel> Unless Tom has other ideas, this seems like the way to go for me.
> 
> Sorry I didn't respond to this earlier.
> I think it's fine for the branch.
>
> I came up with a complicated plan for the trunk, but after some
> reflection, I think a better plan is to notice OBJF_READNOW and refuse
> to do any sharing in this case.  That is, it's your patch, but replacing
> "0" with a check of OBJF_READNOW.  The appended probably has the wrong
> line numbers but it shows the idea.
> 
> This -readnow stuff is an optimization, which in retrospect is kind of
> silly, because on the whole I'd rather people not use -readnow anyway,
> so why bother optimizing.  But when I added the gdb-index code, I
> noticed the possibility and I guess I couldn't resist.
> 
> Tom
> 
> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
> index 11cdcd02d0a..ec044ab66e5 100644
> --- a/gdb/dwarf2/read.c
> +++ b/gdb/dwarf2/read.c
> @@ -1883,9 +1883,11 @@ dwarf2_has_info (struct objfile *objfile,
>      {
>        dwarf2_per_bfd *per_bfd;
>  
> -      /* We can share a "dwarf2_per_bfd" with other objfiles if the BFD
> -	 doesn't require relocations.  */
> -      if (!gdb_bfd_requires_relocations (objfile->obfd))G
> +      /* We can share a "dwarf2_per_bfd" with other objfiles if the
> +	 BFD doesn't require relocations, and if -readnow was never
> +	 requested.  */
> +      if (!gdb_bfd_requires_relocations (objfile->obfd)
> +	  && (objfile->flags & OBJF_READNOW) == 0)
>  	{
>  	  /* See if one has been created for this BFD yet.  */
>  	  per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);

This is fine with me, and I think it's sufficient for now.  It passes
the test I wrote, so I'll adjust my patch to use this and post a v2.

In the general case, I'm not convinced that there aren't more problems
like this, where you load the same BFD with two different "quick"
methods (as mentioned in my commit message).

We currently handle the psymtabs -> index case (commit efb763a5ea35),
necessary for when the index-cache is on.  In that case, we just keep
using the already-created psymtabs the second time around, the index is
just not used.

But imagine an index -> psymtabs case.  I imagine we could eventually
have a "-no-index" switch to the file command and/or a "set use-index
on/off" parameter, to tell GDB to not use any index.  That could be
useful in case the index gives you some trouble and you would like to
read the file without it.  So you could do "file bin" first and "file
-no-index bin" second.  The dwarf2_per_bfd is created using the index
the first time, but we wouldn't want to re-use that dwarf2_per_bfd the
second time.

Only sharing the dwarf2_per_bfd between objfiles that use the same
"quick" method would make me more confident that we won't hit other such
problematic cases.

Simon

Re: GDB 10.2 Release: Proposing Mar 13-14 for official GDB 10.2 release

[Simon Marchi]

On 2021-03-30 3:59 a.m., Joel Brobecker wrote:
> Hi Tom,
> 
> On Mon, Mar 29, 2021 at 11:02:13PM -0600, Tom Tromey wrote:
>>>> diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
>>>> index 704ba9f36655..5d9256bece1e 100644
>>>> --- a/gdb/dwarf2/read.c
>>>> +++ b/gdb/dwarf2/read.c
>>>> @@ -1954,7 +1954,8 @@ dwarf2_has_info (struct objfile *objfile,
>>>> doesn't require relocations and if there aren't partial symbols
>>>> from some other reader.  */
>>>> if (!objfile_has_partial_symbols (objfile)
>>>> -         && !gdb_bfd_requires_relocations (objfile->obfd))
>>>> +         && !gdb_bfd_requires_relocations (objfile->obfd)
>>>> +         && 0)
>>>> {
>>>> /* See if one has been created for this BFD yet.  */
>>>> per_bfd = dwarf2_per_bfd_bfd_data_key.get (objfile->obfd);
>>>>
>>>> We can then take our time to look at a proper fix for master.
>>
>> Joel> It's quite nice to see that this feature could be disabled with
>> Joel> a one-liner like this.
>>
>> Joel> Unless Tom has other ideas, this seems like the way to go for me.
>>
>> Sorry I didn't respond to this earlier.
>> I think it's fine for the branch.
> 
> Great, thank you!
> 
> Speaking of the branch, given your patch below, perhaps we can have
> best of both worlds if we go with the solution you suggest?
> If we could converge on that by the time the weekend comes,
> I think it would be reasonable to backport your patch to the branch
> as well.

This is now pushed.  Quick! Release before any more bugs pop up!

Simon