GDB 8.0 release/branching update (10 more days to branching)

GDB 8.0 release/branching update (10 more days to branching)

[Joel Brobecker]

Hello everyone,

We are now about 10 days away from our tentative date for branching.
First of all, a big thank you for all of you who fixed some of those
PRs that were marked for 8.0!

As of now, we have 3 PRs currently open:

* gdb/21187  Static linking of libstdc++ and libgcc with GDB leads to
             broken exception handling on AIX platform

        I consider this one blocking for release (OK for branching):
        New regression, no easy workaround.

        The person who opened the PR actually sent a patch to
        bugzilla, but I asked him (in Cc: here) to send the patch here,
        so it can be reviewed, and possibly integrated. It's a
        workaround, but it introduces a feature which could also
        be useful in other contexts.

        It should be sufficiently small and obvious that copyright
        assignment not be an issue.

* gdb/21216     regression: TUI by: Eliminate make_cleanup_ui_file_delete
                / make ui_file a class hierarchy

        We should be changing the subject to "missing carriage return
        in TUI mode" or something like that. That's what it is about.

        Clearly a regression, clearly blocking. But the hope is that
        it be relatively simple to fix (from the look of it).
        Already assigned.

* gdb/21169     GDBServer on ARM can crash the inferior while single stepping

        Considered blocking, but only if it doesn't delay the release
        unreasonably.

        Antoine is this PR's champion.

So, all in all, at the moment, I don't think we have anything blocking
for creating the release. But if you know of some other issues, please
let us know.

At this point, we're getting sufficiently close to starting the release
process that I would like people to let me know when they mark
a PR for 8.0 (target milestone field), as this is the signal that
we can't release until it is fixed. And when you do, please explain
what your reasons are.

Thank you!
-- 
Joel

Re: GDB 8.0 release/branching update (10 more days to branching)

[Yao Qi]

On Sat, Mar 4, 2017 at 5:59 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> So, all in all, at the moment, I don't think we have anything blocking
> for creating the release. But if you know of some other issues, please
> let us know.
>

Two issues in my mind,

I raised some questions on new record Python bindings,
https://sourceware.org/ml/gdb-patches/2017-03/msg00023.html
There is not test fail or regression, but it is about python api,
which can't be changed after they are released.  I want to make
them more general, they are too btrace specific so far.  This should
be done by release, IMO.

Current GDB mainline failed to build with old python, and Tim
posted a patch https://sourceware.org/ml/gdb-patches/2017-02/msg00712.html
 I requested Tim to add test case.

I'll go to Linaro Connect next week.  I still check emails, but should
be less active.  I'll take some days off afterwards and back to work
on March 16th.  Then, I'll seriously start pre-release tests for ARM
and AArch64, and fix bugs if any.

-- 
Yao (齐尧)

Re: GDB 8.0 release/branching update (10 more days to branching)

[Joel Brobecker]

Hi Yao,

> Two issues in my mind,

Thanks for the heads up!

> I raised some questions on new record Python bindings,
> https://sourceware.org/ml/gdb-patches/2017-03/msg00023.html
> There is not test fail or regression, but it is about python api,
> which can't be changed after they are released.  I want to make
> them more general, they are too btrace specific so far.  This should
> be done by release, IMO.
> 
> Current GDB mainline failed to build with old python, and Tim
> posted a patch https://sourceware.org/ml/gdb-patches/2017-02/msg00712.html
>  I requested Tim to add test case.

I've added those items to the list of "maybe" blocking before
branching. The first one in particular is worth having before,
I think, because we don't want to have people try a pre-release
with a different API, even if that would probably a marginal
portion of people.

The second one is mostly to avoid getting reports of this not working
when we already know. I could mention this as a known issue, but
it looks like we're not far from a resolution, so, might as well
wait.

> I'll go to Linaro Connect next week.  I still check emails, but should
> be less active.  I'll take some days off afterwards and back to work
> on March 16th.  Then, I'll seriously start pre-release tests for ARM
> and AArch64, and fix bugs if any.

It sounds to me like it would be worth waiting for that testing to be
done before we branch. Say - we could re-evaluate the situation on
March 20th...

-- 
Joel

Re: GDB 8.0 release/branching update (10 more days to branching)

[Pedro Alves]

Hi Joel,

On 03/04/2017 05:59 PM, Joel Brobecker wrote:
> * gdb/21216     regression: TUI by: Eliminate make_cleanup_ui_file_delete
>                 / make ui_file a class hierarchy
> 
>         We should be changing the subject to "missing carriage return
>         in TUI mode" or something like that. That's what it is about.
> 
>         Clearly a regression, clearly blocking. But the hope is that
>         it be relatively simple to fix (from the look of it).
>         Already assigned.

I'm looking at this now.

Thanks,
Pedro Alves

Re: GDB 8.0 release/branching update (10 more days to branching)

[Andreas Arnez]

On Sat, Mar 04 2017, Joel Brobecker wrote:

> Hello everyone,
>
> We are now about 10 days away from our tentative date for branching.
> First of all, a big thank you for all of you who fixed some of those
> PRs that were marked for 8.0!

Probably a bit late, but I'd also like to get these fixes upstream
before the branch:

* gdb/21220  "restore" for large data structures extremely slow on
             GNU/Linux 

A regression from last year that renders "restore" for large data
structures unusable on GNU/Linux.  Proposed fix is available.

* gdb/21226  DW_OP_stack_value pieces yield wrong data on big-endian
             targets 

Causes wrong values to be displayed for certain variables on big-endian
targets.  Not a recent regression, but potentially causes severe
headaches for people running into it.  Proposed fix is available.

--
Andreas