Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Joel Brobecker]

Hi everyone,

Below is another status update before branching. We're almost there,
and if all goes well, I propose we create the branch during the weekend
of Fri-Sun Sep 11-13, immediately followed by creating the first
prerelease.

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

<none>

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

<none> (Yay! ;-) )

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

  * [TomT/HannesD] <PR win32/25302>
    Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
    https://sourceware.org/bugzilla/show_bug.cgi?id=25302

    Latest discussion at:
    https://sourceware.org/pipermail/gdb-patches/2020-June/169670.html
    https://sourceware.org/pipermail/gdb-patches/2020-July/170681.html
    https://sourceware.org/pipermail/gdb-patches/2020-August/171249.html

    Tom sent a patch locally changing gnulib (reviewed and OK-ed by
    yours truly, but with a request to wait a bit before getting it in):
    https://sourceware.org/pipermail/gdb-patches/2020-September/171660.html

  * [TomT] <PR rust/26197>
    rust FAILs with rustc 1.36.0 and llvm 7
    https://sourceware.org/bugzilla/show_bug.cgi?id=26197

    Patch pushed:
    https://sourceware.org/pipermail/gdb-patches/2020-July/170764.html

    At the stage where we are just XFAIL-ing the remaining failures.
    I'd say we have the most important part of the fix, and whatever
    is left can easily be backported to the branch if needed.

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

  <none>

Cheers!
-- 
Joel

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Kamil Rytarowski]

[-- Attachment #1.1: Type: text/plain, Size: 1903 bytes --]

Personally, I would like to see gdbserver for NetBSD/amd64 merged for
GDB 10.

The code is pending upstream and requires more reviewers.

On 05.09.2020 22:53, Joel Brobecker wrote:
> Hi everyone,
> 
> Below is another status update before branching. We're almost there,
> and if all goes well, I propose we create the branch during the weekend
> of Fri-Sun Sep 11-13, immediately followed by creating the first
> prerelease.
> 
> Fixed Since the Previous Update:
> --------------------------------
> 
> <none>
> 
> Added Since the Last Update:
> ----------------------------
> 
> <none> (Yay! ;-) )
> 
> Other Ongoing Items:
> --------------------
> 
>   * [TomT/HannesD] <PR win32/25302>
>     Mismatching fstat() function calls in gdb_bfd_open() and cache_bstat()
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25302
> 
>     Latest discussion at:
>     https://sourceware.org/pipermail/gdb-patches/2020-June/169670.html
>     https://sourceware.org/pipermail/gdb-patches/2020-July/170681.html
>     https://sourceware.org/pipermail/gdb-patches/2020-August/171249.html
> 
>     Tom sent a patch locally changing gnulib (reviewed and OK-ed by
>     yours truly, but with a request to wait a bit before getting it in):
>     https://sourceware.org/pipermail/gdb-patches/2020-September/171660.html
> 
>   * [TomT] <PR rust/26197>
>     rust FAILs with rustc 1.36.0 and llvm 7
>     https://sourceware.org/bugzilla/show_bug.cgi?id=26197
> 
>     Patch pushed:
>     https://sourceware.org/pipermail/gdb-patches/2020-July/170764.html
> 
>     At the stage where we are just XFAIL-ing the remaining failures.
>     I'd say we have the most important part of the fix, and whatever
>     is left can easily be backported to the branch if needed.
> 
> Not Critical, but Requested:
> ----------------------------
> 
>   <none>
> 
> Cheers!
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Simon Marchi]

On 2020-09-06 8:07 p.m., Kamil Rytarowski wrote:
> Personally, I would like to see gdbserver for NetBSD/amd64 merged for
> GDB 10.
> 
> The code is pending upstream and requires more reviewers.

I think that's reasonable.  I just finished taking a look, I did review it
as best as I could.  There's not much risk in merging it, and the sooner this
is available upstream, the better, so I think we should just go ahead with it.

Of course, the more pair of eyes on the code the better, so if somebody else
wants to take a look, go ahead.

I would also consider including the gdbserver support for ARC, with the same
logic.  But I don't think that has to block the branch creation, we can easily
cherry-pick it.

Simon

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Joel Brobecker]

> I think that's reasonable.  I just finished taking a look, I did review it
> as best as I could.  There's not much risk in merging it, and the sooner this
> is available upstream, the better, so I think we should just go ahead with it.
> 
> Of course, the more pair of eyes on the code the better, so if somebody else
> wants to take a look, go ahead.
> 
> I would also consider including the gdbserver support for ARC, with the same
> logic.  But I don't think that has to block the branch creation, we can easily
> cherry-pick it.

I'm not opposed to these going into GDB 10 on the basis that they
are isolated pieces of code that can't affect the rest. On the other
hand, if those can be safely pushed at the last minute, they should
also be cherry-pickable on the branch, so given the very large delay
the branching has already suffered, I would not delay branching
for this new feature further. We can simply cherry-pick those later.
Would that be acceptable?

-- 
Joel

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Kamil Rytarowski]

[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]

On 08.09.2020 15:49, Joel Brobecker wrote:
>> I think that's reasonable.  I just finished taking a look, I did review it
>> as best as I could.  There's not much risk in merging it, and the sooner this
>> is available upstream, the better, so I think we should just go ahead with it.
>>
>> Of course, the more pair of eyes on the code the better, so if somebody else
>> wants to take a look, go ahead.
>>
>> I would also consider including the gdbserver support for ARC, with the same
>> logic.  But I don't think that has to block the branch creation, we can easily
>> cherry-pick it.
> 
> I'm not opposed to these going into GDB 10 on the basis that they
> are isolated pieces of code that can't affect the rest. On the other
> hand, if those can be safely pushed at the last minute, they should
> also be cherry-pickable on the branch, so given the very large delay
> the branching has already suffered, I would not delay branching
> for this new feature further. We can simply cherry-pick those later.
> Would that be acceptable?
> 

Personally, I consider the patchset to be ready to merge, but it depends
on the reviewers with approval privilege.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Simon Marchi]

On 2020-09-08 9:51 a.m., Kamil Rytarowski wrote:
> On 08.09.2020 15:49, Joel Brobecker wrote:
>>> I think that's reasonable.  I just finished taking a look, I did review it
>>> as best as I could.  There's not much risk in merging it, and the sooner this
>>> is available upstream, the better, so I think we should just go ahead with it.
>>>
>>> Of course, the more pair of eyes on the code the better, so if somebody else
>>> wants to take a look, go ahead.
>>>
>>> I would also consider including the gdbserver support for ARC, with the same
>>> logic.  But I don't think that has to block the branch creation, we can easily
>>> cherry-pick it.
>>
>> I'm not opposed to these going into GDB 10 on the basis that they
>> are isolated pieces of code that can't affect the rest. On the other
>> hand, if those can be safely pushed at the last minute, they should
>> also be cherry-pickable on the branch, so given the very large delay
>> the branching has already suffered, I would not delay branching
>> for this new feature further. We can simply cherry-pick those later.
>> Would that be acceptable?
>>
> 
> Personally, I consider the patchset to be ready to merge, but it depends
> on the reviewers with approval privilege.
> 

This is now merged (any post-merge review is welcome, but I believed it looked good enough that we didn't need to delay it further).

Simon

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Christian Biesinger]

On Sat, Sep 5, 2020 at 10:53 PM Joel Brobecker <brobecker@adacore.com> wrote:
>
> Hi everyone,
>
> Below is another status update before branching. We're almost there,
> and if all goes well, I propose we create the branch during the weekend
> of Fri-Sun Sep 11-13, immediately followed by creating the first
> prerelease.

This bug was just filed with patch:
https://sourceware.org/bugzilla/show_bug.cgi?id=26586

It seems like that patch would be good to have for gdb 10, though it
probably doesn't have to block branching.

Christian

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Joel Brobecker]

> > Below is another status update before branching. We're almost there,
> > and if all goes well, I propose we create the branch during the weekend
> > of Fri-Sun Sep 11-13, immediately followed by creating the first
> > prerelease.
> 
> This bug was just filed with patch:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26586
> 
> It seems like that patch would be good to have for gdb 10, though it
> probably doesn't have to block branching.

Thanks for the heads up Cristian. I marked it 10.1 for the target
milestone to remember about it. I agree it's not branch blocking.
It shouldn't be release blocking either because, as far as I can tell,
the problem was also in GDB 8.2 and GDB 9, but given the type of fix
we are talking about, perhaps worth waiting a bit for...

-- 
Joel

Re: Propose GDB 10 branch this Fri-Sun (Sep 11-13) [2020-09-05 Update]

[Simon Marchi]

On 2020-09-05 4:53 p.m., Joel Brobecker wrote:
> Hi everyone,
> 
> Below is another status update before branching. We're almost there,
> and if all goes well, I propose we create the branch during the weekend
> of Fri-Sun Sep 11-13, immediately followed by creating the first
> prerelease.

I found and filed this:

skip compares pattern against mangled name
https://sourceware.org/bugzilla/show_bug.cgi?id=26598

Probably not a blocker for the branch, since a fix can easily be backported.  But it should
be a blocker for the release, given that it was introduced since the last release, so we
have the opportunity to fix it before it is released in the wild.

Simon