GDB 8.1 branching 2017-12-04 update

GDB 8.1 branching 2017-12-04 update

[Joel Brobecker]

Hello,

As far as I know, the issues identified the last time we did
an update on the branch have all been either - defered to the next
release (ARMv8.3-A Pointer Authentication suppport), or pushed.
See: https://sourceware.org/gdb/wiki/GDB_8.1_Release

There are a number of PRs targetting 8.1 however. Should we wait
for those to be fixed before we branch?

  * [TomT] PR breakpoint/22511
    Regression in "commands"

  * [PedroA] PR gdb/Bug 22499
    8.0 regression: wrongly read $xmm0

    Pedro sent a patch for review on Nov 29th, so I think we can wait
    for that one before branching.

  * [SergioDJ] PR cli/16224
    add "pahole" functionality to ptype

    Work is being done as we speak, with some patches sent.
    I think we continue the wait.

In addition, we have the following unassigned PR:

  * [YaoQ???] PR python/22475
  Python API: breakpoint subclass: GDB crashes if function called through parse_and_eval() exits

  Yao - are you working on this PR? I am asking because you marked it
  as targetting 8.1 with the following message: "Set the target
  milestone to 8.1, although it is not a regression from last release.".

I'll continue monitor those PRs closely, and hope that we can branch
by, say, early next week.

Am I missing other issues that you think should block the creation
of the 8.1 branch?

Thank you!
-- 
Joel

Re: GDB 8.1 branching 2017-12-04 update

[Tom Tromey]

Joel>   * [TomT] PR breakpoint/22511
Joel>     Regression in "commands"

I sent a couple of notes about this to the list last week, and I'm
waiting for a reply before proceeding.

Tom

Re: GDB 8.1 branching 2017-12-04 update

[Pedro Alves]

On 12/04/2017 02:56 PM, Joel Brobecker wrote:
> Hello,
> 
> As far as I know, the issues identified the last time we did
> an update on the branch have all been either - defered to the next
> release (ARMv8.3-A Pointer Authentication suppport), or pushed.
> See: https://sourceware.org/gdb/wiki/GDB_8.1_Release
> 
> There are a number of PRs targetting 8.1 however. Should we wait
> for those to be fixed before we branch?
> 
>   * [TomT] PR breakpoint/22511
>     Regression in "commands"
> 
>   * [PedroA] PR gdb/Bug 22499
>     8.0 regression: wrongly read $xmm0
> 
>     Pedro sent a patch for review on Nov 29th, so I think we can wait
>     for that one before branching.
> 
>   * [SergioDJ] PR cli/16224
>     add "pahole" functionality to ptype
> 
>     Work is being done as we speak, with some patches sent.
>     I think we continue the wait.
> 
> In addition, we have the following unassigned PR:
> 
>   * [YaoQ???] PR python/22475
>   Python API: breakpoint subclass: GDB crashes if function called through parse_and_eval() exits
> 
>   Yao - are you working on this PR? I am asking because you marked it
>   as targetting 8.1 with the following message: "Set the target
>   milestone to 8.1, although it is not a regression from last release.".
> 
> I'll continue monitor those PRs closely, and hope that we can branch
> by, say, early next week.
> 
> Am I missing other issues that you think should block the creation
> of the 8.1 branch?

One thing that I was thinking it'd be nice to see about getting
into 8.1 was the DWARF5 index stuff (standard replacement for 
.gdb_index):

 https://sourceware.org/ml/gdb-patches/2017-05/msg00577.html

Not sure about making that the default (seems risky), but it
might be nice to provide the option so that users/distros can
start experimenting (and so that Fedora/RHEL doesn't end up
having to backport yet another large series... :-P) .  I tried
to review that in the past but stumbled  on choices I didn't quite
understand, and there are also some open questions, but I was
planning on taking another look.  I can't really promise I/we can
get it done this week, so not sure about blocking the branching
because of it.

Thanks,
Pedro Alves

Re: GDB 8.1 branching 2017-12-04 update

[Pedro Alves]

On 12/04/2017 03:06 PM, Tom Tromey wrote:
> Joel>   * [TomT] PR breakpoint/22511
> Joel>     Regression in "commands"
> 
> I sent a couple of notes about this to the list last week, and I'm
> waiting for a reply before proceeding.

Sorry, last Friday it was holiday here, and I haven't had a chance
to work through that yet.

Thanks,
Pedro Alves

Re: GDB 8.1 branching 2017-12-04 update

[Yao Qi]

On Mon, Dec 4, 2017 at 2:56 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>
>   * [YaoQ???] PR python/22475
>   Python API: breakpoint subclass: GDB crashes if function called through parse_and_eval() exits
>
>   Yao - are you working on this PR? I am asking because you marked it
>   as targetting 8.1 with the following message: "Set the target
>   milestone to 8.1, although it is not a regression from last release.".

No, I am not working on this.  I am still testing ARM and AArch64 GDB,
no extra cycles on this now.  I may take a look at it if I finish all ARM and
AArch64 GDB testing, and 8.1 is not released yet.

Can I clear the target of PR python/22475?

-- 
Yao (齐尧)

Re: GDB 8.1 branching 2017-12-04 update

[Pedro Alves]

On 12/04/2017 02:56 PM, Joel Brobecker wrote:
>   * [PedroA] PR gdb/Bug 22499
>     8.0 regression: wrongly read $xmm0
> 
>     Pedro sent a patch for review on Nov 29th, so I think we can wait
>     for that one before branching.

I pushed this one in now.

Thanks,
Pedro Alves

Re: GDB 8.1 branching 2017-12-04 update

[Joel Brobecker]

> On Mon, Dec 4, 2017 at 2:56 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> >
> >   * [YaoQ???] PR python/22475
> >   Python API: breakpoint subclass: GDB crashes if function called through parse_and_eval() exits
> >
> >   Yao - are you working on this PR? I am asking because you marked it
> >   as targetting 8.1 with the following message: "Set the target
> >   milestone to 8.1, although it is not a regression from last release.".
> 
> No, I am not working on this.  I am still testing ARM and AArch64 GDB,
> no extra cycles on this now.  I may take a look at it if I finish all ARM and
> AArch64 GDB testing, and 8.1 is not released yet.
> 
> Can I clear the target of PR python/22475?

Yes, let's clear it if there are no reason real reason to put
additional pressure on us.

Thank you!
-- 
Joel

Re: GDB 8.1 branching 2017-12-04 update

[Joel Brobecker]

> One thing that I was thinking it'd be nice to see about getting
> into 8.1 was the DWARF5 index stuff (standard replacement for 
> .gdb_index):
> 
>  https://sourceware.org/ml/gdb-patches/2017-05/msg00577.html
> 
> Not sure about making that the default (seems risky), but it
> might be nice to provide the option so that users/distros can
> start experimenting (and so that Fedora/RHEL doesn't end up
> having to backport yet another large series... :-P) .  I tried
> to review that in the past but stumbled  on choices I didn't quite
> understand, and there are also some open questions, but I was
> planning on taking another look.  I can't really promise I/we can
> get it done this week, so not sure about blocking the branching
> because of it.

Indeed, it would be nice, and we can wait a bit to see if we manage
to get it in. But looking at the size of the patch, unless you think
it's almost ready and it's only a matter of a few fixes here and
there, it seems like this might be a bit risky...

Let's give ourselves this week, and see where we get. In the meantime,
I've added this to the "maybe" section, before 18.1 branching.

-- 
Joel

Re: GDB 8.1 branching 2017-12-04 update

[Sergio Durigan Junior]

On Monday, December 04 2017, Joel Brobecker wrote:

>   * [SergioDJ] PR cli/16224
>     add "pahole" functionality to ptype

I've pinged this patch today.  Eli has already approved the docs.

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.1 branching 2017-12-04 update

[Pedro Alves]

On 12/04/2017 05:02 PM, Joel Brobecker wrote:
>> One thing that I was thinking it'd be nice to see about getting
>> into 8.1 was the DWARF5 index stuff (standard replacement for 
>> .gdb_index):
>>
>>  https://sourceware.org/ml/gdb-patches/2017-05/msg00577.html
>>
>> Not sure about making that the default (seems risky), but it
>> might be nice to provide the option so that users/distros can
>> start experimenting (and so that Fedora/RHEL doesn't end up
>> having to backport yet another large series... :-P) .  I tried
>> to review that in the past but stumbled  on choices I didn't quite
>> understand, and there are also some open questions, but I was
>> planning on taking another look.  I can't really promise I/we can
>> get it done this week, so not sure about blocking the branching
>> because of it.
> 
> Indeed, it would be nice, and we can wait a bit to see if we manage
> to get it in. But looking at the size of the patch, unless you think
> it's almost ready and it's only a matter of a few fixes here and
> there, it seems like this might be a bit risky...
> 

I've played around with that series for a few days (on and off...),
and I've now pushed it in, with an important change that eliminates
most of the risk, IMO -- the original series made GDB default
to the new index format, while I left .gdb_index the default.
This should allow users/distros experimenting, and hopefully
any follow up fixes should be small/contained and easy to backport.

> Let's give ourselves this week, and see where we get. In the meantime,
> I've added this to the "maybe" section, before 18.1 branching.

Thanks,
Pedro Alves

Re: GDB 8.1 branching 2017-12-04 update

[Joel Brobecker]

> >> One thing that I was thinking it'd be nice to see about getting
> >> into 8.1 was the DWARF5 index stuff (standard replacement for 
> >> .gdb_index):
> >>
> >>  https://sourceware.org/ml/gdb-patches/2017-05/msg00577.html
[...]
> I've played around with that series for a few days (on and off...),
> and I've now pushed it in, with an important change that eliminates
> most of the risk, IMO -- the original series made GDB default
> to the new index format, while I left .gdb_index the default.
> This should allow users/distros experimenting, and hopefully
> any follow up fixes should be small/contained and easy to backport.

Makes sense indeed! Thanks for doing that, Pedro.

-- 
Joel