start of the GDB 11 release cycle

start of the GDB 11 release cycle

[Joel Brobecker]

Hello,

It's been about 6.5 months since we made the first GDB 10 release (10.1).
So I propose we start the process of creating the GDB 11 release now.

As of now, below are the issues that I'm aware of:

  * [Sergey with Simon as reviewer] <PR tdep/26633>
    Add Z80 CPU support
    https://sourceware.org/bugzilla/show_bug.cgi?id=26633

    Patch submitted at:
    https://sourceware.org/pipermail/gdb-patches/2020-September/172083.html

  * [AndrewB/Simon] <PR gdb/26819>
    Bug 26819 - RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
    https://sourceware.org/bugzilla/show_bug.cgi?id=26819

    I think the situation has been improved thanks to a couple of
    patches, but the user still has some scenarios where the issue
    happens.

  * [Simon] <PR gdb/26868>
    Follow-up on x86-64 stub submission
    https://sourceware.org/bugzilla/show_bug.cgi?id=26868

    This is the submission in question:
    https://sourceware.org/pipermail/gdb-patches/2020-November/173182.html

  * [Simon/Kevin] <PR gdb/27526>
    Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"

    Patch v2 at:
    https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html

Are there other issues or last minute features we'd like to include
before we branch and/or release?

Thank you!
-- 
Joel

Re: start of the GDB 11 release cycle

[Mike Frysinger]

On 09 May 2021 17:04, Joel Brobecker wrote:
> Are there other issues or last minute features we'd like to include
> before we branch and/or release?

i have some patches pending for using gnulib in sim ... waiting on gcc side to
approve a top-level patch.  they're not needed for up-to-date platforms, but
to fix builds for systems like Windows that don't fully support current POSIX.
-mike

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> > Are there other issues or last minute features we'd like to include
> > before we branch and/or release?
> 
> i have some patches pending for using gnulib in sim ... waiting on gcc side to
> approve a top-level patch.  they're not needed for up-to-date platforms, but
> to fix builds for systems like Windows that don't fully support current POSIX.

Understood. Please let me know when the patches are approved and in,
so I can scratch this one off the list.

-- 
Joel

Re: start of the GDB 11 release cycle

[Joel Brobecker]

Hi Mike,

> On 09 May 2021 17:04, Joel Brobecker wrote:
> > Are there other issues or last minute features we'd like to include
> > before we branch and/or release?
> 
> i have some patches pending for using gnulib in sim ... waiting on gcc
> side to approve a top-level patch.  they're not needed for up-to-date
> platforms, but to fix builds for systems like Windows that don't fully
> support current POSIX.

How are we doing on this front? If you've posted patches, would
you mind giving me URLs, so I can follow their progress?

Thank you!
-- 
Joel

Re: start of the GDB 11 release cycle

[Mike Frysinger]

On 24 May 2021 12:40, Joel Brobecker wrote:
> > On 09 May 2021 17:04, Joel Brobecker wrote:
> > > Are there other issues or last minute features we'd like to include
> > > before we branch and/or release?
> > 
> > i have some patches pending for using gnulib in sim ... waiting on gcc
> > side to approve a top-level patch.  they're not needed for up-to-date
> > platforms, but to fix builds for systems like Windows that don't fully
> > support current POSIX.
> 
> How are we doing on this front? If you've posted patches, would
> you mind giving me URLs, so I can follow their progress?

i got some reviewed & merged yesterday & today.  i'm down to the last:
https://sourceware.org/pipermail/gdb-patches/2021-May/179202.html
-mike

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> i got some reviewed & merged yesterday & today.  i'm down to the last:
> https://sourceware.org/pipermail/gdb-patches/2021-May/179202.html

Awesome. Thanks Mike.

-- 
Joel

Re: start of the GDB 11 release cycle

[Mike Frysinger]

On 26 May 2021 15:03, Joel Brobecker wrote:
> > i got some reviewed & merged yesterday & today.  i'm down to the last:
> > https://sourceware.org/pipermail/gdb-patches/2021-May/179202.html
> 
> Awesome. Thanks Mike.

i should be all merged now
-mike

Re: start of the GDB 11 release cycle

[Luis Machado]

Hi Joel,

On 5/9/21 9:04 PM, Joel Brobecker wrote:
> Hello,
> 
> It's been about 6.5 months since we made the first GDB 10 release (10.1).
> So I propose we start the process of creating the GDB 11 release now.
> 
> As of now, below are the issues that I'm aware of:
> 
>    * [Sergey with Simon as reviewer] <PR tdep/26633>
>      Add Z80 CPU support
>      https://sourceware.org/bugzilla/show_bug.cgi?id=26633
> 
>      Patch submitted at:
>      https://sourceware.org/pipermail/gdb-patches/2020-September/172083.html
> 
>    * [AndrewB/Simon] <PR gdb/26819>
>      Bug 26819 - RISC-V: internal-error: int finish_step_over(execution_control_state*): Assertion
>      https://sourceware.org/bugzilla/show_bug.cgi?id=26819
> 
>      I think the situation has been improved thanks to a couple of
>      patches, but the user still has some scenarios where the issue
>      happens.
> 
>    * [Simon] <PR gdb/26868>
>      Follow-up on x86-64 stub submission
>      https://sourceware.org/bugzilla/show_bug.cgi?id=26868
> 
>      This is the submission in question:
>      https://sourceware.org/pipermail/gdb-patches/2020-November/173182.html
> 
>    * [Simon/Kevin] <PR gdb/27526>
>      Attaching to threaded process on glibc 2.33: libthread_db fails to initialize with "generic error"
> 
>      Patch v2 at:
>      https://sourceware.org/pipermail/gdb-patches/2021-May/178485.html
> 
> Are there other issues or last minute features we'd like to include
> before we branch and/or release?

For issues, I have a couple that I'd like to get fixed for AArch64 MTE 
before GDB 11. I'll file those in bugzilla and will set the fields 
accordingly.

In terms of features, I'd really like to get AArch64 MTE core file 
support (dumping registers and memory tags) in before GDB 11. I don't 
expect it to be a big change, but I'm still polishing the series so I 
can submit it.

Given this step needs coordination with the kernel, there might be 
delays here and there. Do you think that will be acceptable?

Re: start of the GDB 11 release cycle

[Joel Brobecker]

Hi Luis,

> For issues, I have a couple that I'd like to get fixed for AArch64 MTE
> before GDB 11. I'll file those in bugzilla and will set the fields
> accordingly.
> 
> In terms of features, I'd really like to get AArch64 MTE core file support
> (dumping registers and memory tags) in before GDB 11. I don't expect it to
> be a big change, but I'm still polishing the series so I can submit it.
> 
> Given this step needs coordination with the kernel, there might be delays
> here and there. Do you think that will be acceptable?

Do you have a rough idea of how long this would take?

-- 
Joel

Re: start of the GDB 11 release cycle

[Luis Machado]

On 5/10/21 7:11 PM, Joel Brobecker wrote:
> Hi Luis,
> 
>> For issues, I have a couple that I'd like to get fixed for AArch64 MTE
>> before GDB 11. I'll file those in bugzilla and will set the fields
>> accordingly.
>>
>> In terms of features, I'd really like to get AArch64 MTE core file support
>> (dumping registers and memory tags) in before GDB 11. I don't expect it to
>> be a big change, but I'm still polishing the series so I can submit it.
>>
>> Given this step needs coordination with the kernel, there might be delays
>> here and there. Do you think that will be acceptable?
> 
> Do you have a rough idea of how long this would take?
> 

I have an implementation I can send within a couple weeks. From the 
kernel's side, we just need to agree on the core file format.

So my guesstimate is 3 to 4 weeks.

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> I have an implementation I can send within a couple weeks. From the kernel's
> side, we just need to agree on the core file format.
> 
> So my guesstimate is 3 to 4 weeks.

Alright. Let's see how it goes. I'm thinking that if this is still
ongoing by the time we are otherwise ready to create the branch,
we can go ahead with the branch, and then backport your changes
afterwards. Normally, the risk should be fairly low and limited
to just this target.

-- 
Joel

Re: start of the GDB 11 release cycle

[Luis Machado]

Joel,

On 5/11/21 2:00 PM, Joel Brobecker wrote:
>> I have an implementation I can send within a couple weeks. From the kernel's
>> side, we just need to agree on the core file format.
>>
>> So my guesstimate is 3 to 4 weeks.
> 
> Alright. Let's see how it goes. I'm thinking that if this is still
> ongoing by the time we are otherwise ready to create the branch,
> we can go ahead with the branch, and then backport your changes
> afterwards. Normally, the risk should be fairly low and limited
> to just this target.

Sounds reasonable. I expect the impact will be small indeed. I'll try to 
expedite this.

Re: start of the GDB 11 release cycle

[Joel Brobecker]

Hello Luis,

> For issues, I have a couple that I'd like to get fixed for AArch64 MTE
> before GDB 11. I'll file those in bugzilla and will set the fields
> accordingly.

Would you mind creating the bugzilla entries? If you have patches
pending, would you mind also including them in the comment section
of new entries. It'll make it easier for me to keep track of this one
and not forget.

Other than that, how is that activity going? Do you feel like you are
making the progress you were hoping for?

Thank you!

-- 
Joel

Re: start of the GDB 11 release cycle

[Luis Machado]

Hi Joel,

On 5/24/21 4:42 PM, Joel Brobecker wrote:
> Hello Luis,
> 
>> For issues, I have a couple that I'd like to get fixed for AArch64 MTE
>> before GDB 11. I'll file those in bugzilla and will set the fields
>> accordingly.
> 
> Would you mind creating the bugzilla entries? If you have patches
> pending, would you mind also including them in the comment section
> of new entries. It'll make it easier for me to keep track of this one
> and not forget.

Sorry, I dropped the ball on this. Since all of the required patches are 
on the list being reviewed (I sent them last week), I did not create 
tickets for those.

I think I should still do that to make your life easier though. I'm 
thinking a single ticket tracking the 4 or 5 patches related to it. 
Would that work?

> 
> Other than that, how is that activity going? Do you feel like you are
> making the progress you were hoping for?

Yes. The patches are not too big and I got some helpful positive 
reviews. I'm expecting to be able to push a final version in a week or so.

> 
> Thank you!
> 

Re: start of the GDB 11 release cycle

[Joel Brobecker]

Hi Luis,

> > > For issues, I have a couple that I'd like to get fixed for AArch64 MTE
> > > before GDB 11. I'll file those in bugzilla and will set the fields
> > > accordingly.
> > 
> > Would you mind creating the bugzilla entries? If you have patches
> > pending, would you mind also including them in the comment section
> > of new entries. It'll make it easier for me to keep track of this one
> > and not forget.
> 
> Sorry, I dropped the ball on this. Since all of the required patches are on
> the list being reviewed (I sent them last week), I did not create tickets
> for those.
> 
> I think I should still do that to make your life easier though. I'm thinking
> a single ticket tracking the 4 or 5 patches related to it. Would that work?

Thanks Luis. This would work. That being said, if you prefer giving
me URLs of the patch series, as long as the subject doesn't change
from one version to the next, I don't mind following that instead.
I only mentioned it because you originally proposed to do it that way.
I would do what's simplest for you.

> > Other than that, how is that activity going? Do you feel like you are
> > making the progress you were hoping for?
> 
> Yes. The patches are not too big and I got some helpful positive reviews.
> I'm expecting to be able to push a final version in a week or so.

Nice, well done ;-).

-- 
Joel

Re: start of the GDB 11 release cycle

[Luis Machado]

Joel,

On 5/24/21 6:02 PM, Joel Brobecker wrote:
> Hi Luis,
> 
>>>> For issues, I have a couple that I'd like to get fixed for AArch64 MTE
>>>> before GDB 11. I'll file those in bugzilla and will set the fields
>>>> accordingly.
>>>
>>> Would you mind creating the bugzilla entries? If you have patches
>>> pending, would you mind also including them in the comment section
>>> of new entries. It'll make it easier for me to keep track of this one
>>> and not forget.
>>
>> Sorry, I dropped the ball on this. Since all of the required patches are on
>> the list being reviewed (I sent them last week), I did not create tickets
>> for those.
>>
>> I think I should still do that to make your life easier though. I'm thinking
>> a single ticket tracking the 4 or 5 patches related to it. Would that work?
> 
> Thanks Luis. This would work. That being said, if you prefer giving
> me URLs of the patch series, as long as the subject doesn't change
> from one version to the next, I don't mind following that instead.
> I only mentioned it because you originally proposed to do it that way.
> I would do what's simplest for you.

Here it is:

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

> 
>>> Other than that, how is that activity going? Do you feel like you are
>>> making the progress you were hoping for?
>>
>> Yes. The patches are not too big and I got some helpful positive reviews.
>> I'm expecting to be able to push a final version in a week or so.
> 
> Nice, well done ;-).
> 

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> > Thanks Luis. This would work. That being said, if you prefer giving
> > me URLs of the patch series, as long as the subject doesn't change
> > from one version to the next, I don't mind following that instead.
> > I only mentioned it because you originally proposed to do it that way.
> > I would do what's simplest for you.
> 
> Here it is:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27909

Perfect. Thanks Luis!

-- 
Joel

Re: start of the GDB 11 release cycle

[Bernd Edlinger]

Hi Joel,

On 5/10/21 2:04 AM, Joel Brobecker wrote:
> 
> Are there other issues or last minute features we'd like to include
> before we branch and/or release?
> 
> Thank you!
> 

I think my patch to improve the debug experience of optimized code
is stable since january and might also be a good candidiate:

[PATCH 0/4] Improve debugging of optimized code
https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html


Thanks
Bernd.

Re: start of the GDB 11 release cycle

[Simon Marchi]

On 2021-05-10 1:52 a.m., Bernd Edlinger wrote:
> I think my patch to improve the debug experience of optimized code
> is stable since january and might also be a good candidiate:
> 
> [PATCH 0/4] Improve debugging of optimized code
> https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html

I agree, however it's a matter of determining who is most qualified to
review this, it's not easy.  I don't think I'm the best person for
this.

Simon

Re: start of the GDB 11 release cycle

[Andrew Burgess]

* Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> [2021-05-10 11:10:32 -0400]:

> On 2021-05-10 1:52 a.m., Bernd Edlinger wrote:
> > I think my patch to improve the debug experience of optimized code
> > is stable since january and might also be a good candidiate:
> > 
> > [PATCH 0/4] Improve debugging of optimized code
> > https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html
> 
> I agree, however it's a matter of determining who is most qualified to
> review this, it's not easy.  I don't think I'm the best person for
> this.

I don't claim to be the best, but I have an interest in reviewing this
patch.  I'll try to take a look as soon as I can, but if anyone else
wanted to look too that would be great.

Thanks,
Andrew

Re: start of the GDB 11 release cycle

[Simon Marchi]

On 2021-05-10 12:07 p.m., Andrew Burgess wrote:
> I don't claim to be the best, but I have an interest in reviewing this
> patch.  I'll try to take a look as soon as I can, but if anyone else
> wanted to look too that would be great.

Then I'll do it for you: I claim you are the best ;)

Simon

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> > Are there other issues or last minute features we'd like to include
> > before we branch and/or release?
> > 
> > Thank you!
> > 
> 
> I think my patch to improve the debug experience of optimized code
> is stable since january and might also be a good candidiate:
> 
> [PATCH 0/4] Improve debugging of optimized code
> https://sourceware.org/pipermail/gdb-patches/2021-January/175617.html

Understood. Thanks for the heads up and corresponding link.
We'll wait for that one.

-- 
Joel

Re: start of the GDB 11 release cycle

[Rainer Orth]

Hi Joel,

> It's been about 6.5 months since we made the first GDB 10 release (10.1).
> So I propose we start the process of creating the GDB 11 release now.
[...]
> Are there other issues or last minute features we'd like to include
> before we branch and/or release?

I've just tried a sparcv9-sun-solaris2.11 build of gdb master and found
that there are hundreds of testsuite regressions, unlike
amd64-pc-solaris2.11 which is effectively unchanged.  It turned out that
this is a known issue already reported (only for binutils previously) in
PR binutils/27666.

The easiest (and safest) course of action is to revert the
bfd/config.bfd part of Alan's original patch, I believe.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: start of the GDB 11 release cycle

[Joel Brobecker]

> > It's been about 6.5 months since we made the first GDB 10 release (10.1).
> > So I propose we start the process of creating the GDB 11 release now.
> [...]
> > Are there other issues or last minute features we'd like to include
> > before we branch and/or release?
> 
> I've just tried a sparcv9-sun-solaris2.11 build of gdb master and found
> that there are hundreds of testsuite regressions, unlike
> amd64-pc-solaris2.11 which is effectively unchanged.  It turned out that
> this is a known issue already reported (only for binutils previously) in
> PR binutils/27666.
> 
> The easiest (and safest) course of action is to revert the
> bfd/config.bfd part of Alan's original patch, I believe.

Thanks for the heads up, Rainer.

I'll follow that one as well. Worse case scenario, if there is
a delay in the actual fix, we can go with the revert you mentioned
right after we've created the branch, so we have a backup plan.

-- 
Joel