GDB 8.2 branch 2018-06-22 Update

GDB 8.2 branch 2018-06-22 Update

[Joel Brobecker]

Hi everyone,

Can we do a quick status update on the branch? Below are items that
were discussed previously. For those items that are still in progress,
can you tell us whether or not you think you'll be able to finish it
by end of this month?

Note that, for practical reasons, the window for branching is either
end of this month, or end of July.

As far as I know, the following items are now complete:

  * (AlanH) gdb/gdbserver support for aarch64 SVE
    Looks like the code is now in? :-)

    [v3] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html
    [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html

  * (AndrewB) gdb: Don't drop SIGSTOP during stop_all_threads
    Latest update: Reviewed and mostly OK'ed (minor comments)
    Waiting for next version of the patch.
    https://www.sourceware.org/ml/gdb-patches/2018-06/msg00284.html

The following items are still in progress:

  * (PhilippeW) Implement 'frame apply COMMAND', enhance 'thread apply COMMAND'

        It looks like a review was done around Jun 12-15, and some
        discussions, but no v3 yet.

        [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00118.html

  * (SergioDJ) Implement IPv6 support for GDB/gdbserver

        From what I can tell, a v2 was sent, and a review done just
        a couple of days ago. Is that accurate?

        [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html
        [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html

I will add the following issue I discovered to the list as well:

  * (JoelB) SEGV on x86_64-windows due to fs_base/gs_base

        Not necessarily entirely crippling, but crashes GDB as soon
        as we make it try to access the fs_base/gs_base registers.
        For instance: "info reg", or inferior function call
        (presuming that print $fs_base/print $gs_base is unlikely)

        I have a patch that I will share momentarily. I think it's
        simple-enough that it should be in by end of month.

Anything else?

Thank you!
-- 
Joel

Re: GDB 8.2 branch 2018-06-22 Update

[Simon Marchi]

On 2018-06-22 10:05, Joel Brobecker wrote:
> Hi everyone,
> 
> Can we do a quick status update on the branch? Below are items that
> were discussed previously. For those items that are still in progress,
> can you tell us whether or not you think you'll be able to finish it
> by end of this month?
> 
> Note that, for practical reasons, the window for branching is either
> end of this month, or end of July.
> 
> As far as I know, the following items are now complete:
> 
>   * (AlanH) gdb/gdbserver support for aarch64 SVE
>     Looks like the code is now in? :-)
> 
>     [v3] 
> https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html
>     [v2] 
> https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html

Yes I think this is done.

>   * (AndrewB) gdb: Don't drop SIGSTOP during stop_all_threads
>     Latest update: Reviewed and mostly OK'ed (minor comments)
>     Waiting for next version of the patch.
>     https://www.sourceware.org/ml/gdb-patches/2018-06/msg00284.html

This looks like it's in too.

Simon

Re: GDB 8.2 branch 2018-06-22 Update

[Joel Brobecker]

> Can we do a quick status update on the branch? Below are items that
> were discussed previously. For those items that are still in progress,
> can you tell us whether or not you think you'll be able to finish it
> by end of this month?

I forgot to add the items that Tom mentioned -- sorry Tom!

  * (volunteer? else TomT) PR breakpoints/23300
    `commands` does not work correctly if abbreviated to `comm`

        Suspected regression.

  * (???) PR mi/23312 
    MI producing invalid records following redirection (m_suppress_field_separator)

        My understanding from Tom's message was that it was perhaps
        a regression, but looking at the report, it seems to indicate
        that 7.12 is affected too?

-- 
Joel

Re: GDB 8.2 branch 2018-06-22 Update

[Alan Hayward]

> 
> On 22 Jun 2018, at 15:05, Joel Brobecker <brobecker@adacore.com> wrote:
> 
> Hi everyone,
> 
> Can we do a quick status update on the branch? Below are items that
> were discussed previously. For those items that are still in progress,
> can you tell us whether or not you think you'll be able to finish it
> by end of this month?
> 
> Note that, for practical reasons, the window for branching is either
> end of this month, or end of July.
> 
> As far as I know, the following items are now complete:
> 
> * (AlanH) gdb/gdbserver support for aarch64 SVE
>   Looks like the code is now in? :-)
> 
>   [v3] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00400.html
>   [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00145.html
> 

Yes, all my SVE work is in now (Only just - I committed the core file
patch about two minutes ago!).

Happy for the branch to go ahead whenever.

I’m going to see if I can get my full SVE core support patch in too.
However - please don’t delay the branch for it. I had it as a stretch 
goal, and if it makes it then great, if not it can wait. I’m still
working on it, with a few bits yet to figure out.


Alan.

Re: GDB 8.2 branch 2018-06-22 Update

[Sergio Durigan Junior]

On Friday, June 22 2018, Joel Brobecker wrote:

> Hi everyone,

Hey Joel,

>   * (SergioDJ) Implement IPv6 support for GDB/gdbserver
>
>         From what I can tell, a v2 was sent, and a review done just
>         a couple of days ago. Is that accurate?
>
>         [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html
>         [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html

Yes, that is accurate.  I'm now working on addressing a few aspects of
the review, but it is still a bit unclear to me whether my new approach
will be accepted or whether Pedro's suggested approach will work without
problems.  I'm doing some testing to determine what to do next.

I'd like to know: if, for some reason, I'm unable to get this patch
accepted until, say, next Thursday (June 28th), would it be OK to remove
it from the list of blockers, and to backport it to the branch later?
I'm asking because I don't want to be the one blocking the branching
from happening, since the IPv6 feature is not a major regression/problem
to be fixed anyway.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: GDB 8.2 branch 2018-06-22 Update

[Joel Brobecker]

Hi Sergio,

> >   * (SergioDJ) Implement IPv6 support for GDB/gdbserver
> >
> >         From what I can tell, a v2 was sent, and a review done just
> >         a couple of days ago. Is that accurate?
> >
> >         [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00384.html
> >         [v1] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00238.html
> 
> Yes, that is accurate.  I'm now working on addressing a few aspects of
> the review, but it is still a bit unclear to me whether my new approach
> will be accepted or whether Pedro's suggested approach will work without
> problems.  I'm doing some testing to determine what to do next.

Thanks for the update.

> I'd like to know: if, for some reason, I'm unable to get this patch
> accepted until, say, next Thursday (June 28th), would it be OK to remove
> it from the list of blockers, and to backport it to the branch later?
> I'm asking because I don't want to be the one blocking the branching
> from happening, since the IPv6 feature is not a major regression/problem
> to be fixed anyway.

It depends on how intrusive the patch is, so it's a judgement call.
For patches that are really obviously safe, or for which we can say
that they cannot affect anything but themselves, the decision is
fairly easy. For other patches, we need to weigh the benefits vs
the risk we are taking.

One thing we could be doing is cut the branch, but then wait for
the branch to contain the changes we want before we create the first
pre-release. The pre-release tarballs are our last change for field
testing before we issue the first release, and in the case of a riskier
than usual patch, it can be one way to compromise.  We've only done it
once or twice, if memory serves, and the context was that there was
a difficult bug deemed critical that needed time to be fixed. Rather
than holding people's changes for master up while we spent time fixing
master, we just branched, knowing that we would have to backport the fix
before we could generate the first pre-release.

Who decides? I tend to defer to the maintainers who approved the patch
for master. But if, for some reason, the maintainer doesn't feel like
they can decide on their own, I am always happy to take a look and
provide my opinion on the matter -- it is just sometimes a bit more
difficult for me to make a fair assessment, not being entirely
familiar with the patch.

Scanning through v2 of your patch, my first reaction is that it seems
a bit risky to be backporting this to the branch, as it touches the
IPv4 layer quite a bit; it might be a lot of mechanical changes, but
what it shows is that it needs a careful analysis of the risk we are
taking. Having reviewed the patches in more details already, Pedro
might be better placed to let you know the changes of getting it in
after the branch.

You might also want to think about this another way: If you rush
your changes now and then we discover a major and difficult-to-fix bug,
it's less pressure to have to fix it on master, than it is to have
to do an emergency fix on the branch, possibly followed by an emergency
release... I say this not to discourage people, but to make sure that
the extra motivation of making a release doesn't turn into an unnecessary
constraint.

-- 
Joel

Re: GDB 8.2 branch 2018-06-22 Update

[Sergio Durigan Junior]

On Friday, June 22 2018, Joel Brobecker wrote:

>> I'd like to know: if, for some reason, I'm unable to get this patch
>> accepted until, say, next Thursday (June 28th), would it be OK to remove
>> it from the list of blockers, and to backport it to the branch later?
>> I'm asking because I don't want to be the one blocking the branching
>> from happening, since the IPv6 feature is not a major regression/problem
>> to be fixed anyway.
>
> It depends on how intrusive the patch is, so it's a judgement call.
> For patches that are really obviously safe, or for which we can say
> that they cannot affect anything but themselves, the decision is
> fairly easy. For other patches, we need to weigh the benefits vs
> the risk we are taking.
>
> One thing we could be doing is cut the branch, but then wait for
> the branch to contain the changes we want before we create the first
> pre-release. The pre-release tarballs are our last change for field
> testing before we issue the first release, and in the case of a riskier
> than usual patch, it can be one way to compromise.  We've only done it
> once or twice, if memory serves, and the context was that there was
> a difficult bug deemed critical that needed time to be fixed. Rather
> than holding people's changes for master up while we spent time fixing
> master, we just branched, knowing that we would have to backport the fix
> before we could generate the first pre-release.
>
> Who decides? I tend to defer to the maintainers who approved the patch
> for master. But if, for some reason, the maintainer doesn't feel like
> they can decide on their own, I am always happy to take a look and
> provide my opinion on the matter -- it is just sometimes a bit more
> difficult for me to make a fair assessment, not being entirely
> familiar with the patch.
>
> Scanning through v2 of your patch, my first reaction is that it seems
> a bit risky to be backporting this to the branch, as it touches the
> IPv4 layer quite a bit; it might be a lot of mechanical changes, but
> what it shows is that it needs a careful analysis of the risk we are
> taking. Having reviewed the patches in more details already, Pedro
> might be better placed to let you know the changes of getting it in
> after the branch.

Thanks for the throrough explanation, it's always good to understand
more about the whole process.

I agree with you: the patch is a bit risky, indeed.  Even though I'm
trying to extend the existing tests and make sure that it works as it
should, there's always the possibility of making a mistake, especially
if we rush things.

> You might also want to think about this another way: If you rush
> your changes now and then we discover a major and difficult-to-fix bug,
> it's less pressure to have to fix it on master, than it is to have
> to do an emergency fix on the branch, possibly followed by an emergency
> release... I say this not to discourage people, but to make sure that
> the extra motivation of making a release doesn't turn into an unnecessary
> constraint.

You're absolutely right.  I've been thinking about that myself, and
that's why I decided to send the e-mail and ask more details about the
process of backporting.  Curiously, we at Red Hat have had to discuss a
very similar situation involving this same patch, and we also decided to
postpone including it in a next RHEL GDB release for the same reason.

Having said all that, I would like to request the removal of the IPv6
patch from the list of blocking features for the branch.  I think it's
better for Pedro as well, because this way he doesn't have to try to
review things like crazy before next weekend.

Thanks a lot,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: GDB 8.2 branch 2018-06-22 Update

[Philippe Waroquiers]

On Fri, 2018-06-22 at 10:05 -0400, Joel Brobecker wrote:
> The following items are still in progress:
> 
>   * (PhilippeW) Implement 'frame apply COMMAND', enhance 'thread apply COMMAND'
> 
>         It looks like a review was done around Jun 12-15, and some
>         discussions, but no v3 yet.
> 
>         [v2] https://www.sourceware.org/ml/gdb-patches/2018-06/msg00118.html

Hello Joel,

I could not work earlier on the comments, the last 2 weeks
were difficult for me.

I am busy working on v3, I should be able to submit a new version
in the next 2..3 days, as I can spend some time on this this week-end and
the next evenings.

Of course, this patch can go in the next release, if you deem it is better.

Thanks

Philippe
 

Re: GDB 8.2 branch 2018-06-22 Update

[Pedro Franco de Carvalho]

Joel Brobecker <brobecker@adacore.com> writes:

> Anything else?

Hello,

I'm still working on enabling more registers in powerpc, and there's a
chance it might be ready by the end of the week.

However, the number of new registers breaks a use case with tracepoints
due to an internal buffer size. I have submitted patches to improve this
[1], and I'm addressing the comments from Ulrich's review. These affect
the core parts of gdb, not only powerpc.

[1] https://sourceware.org/ml/gdb-patches/2018-06/msg00501.html

Thanks!

--
Pedro Franco de Carvalho