This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: branching for GDB 7.11 soon? (possibly Wed)
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org, sergiodj at redhat dot com, Yao Qi <yao at codesourcery dot com>, Pedro Alves <palves at redhat dot com>, keiths at redhat dot com
- Date: Tue, 9 Feb 2016 15:56:17 +0400
- Subject: Re: RFC: branching for GDB 7.11 soon? (possibly Wed)
- Authentication-results: sourceware.org; auth=none
- References: <20160201030638 dot GG4008 at adacore dot com> <20160207081230 dot GA20874 at adacore dot com>
Hello everyone,
Once again, I am very grateful to everyone who is so responsive
in trying to help us create that branch!
Quick status update again, based on the latest feedback:
> > PR19506 Regression with gdb.Breakpoint("*<addr>")
>
> This lead to a wider fix:
> [PATCH V2 0/4] Add support for "legacy" linespecs
> https://www.sourceware.org/ml/gdb-patches/2016-02/msg00024.html
I took a look over the weekend, and it seems fairly unintrusive.
I propose we push it now. Otherwise, I think it's safe to create
the branch before pushing this patch, and backport afterwards.
> PR 19548 - breakpoint re-set inserts breakpoints when it shouldn't
> Pedro sent a patch:
> https://sourceware.org/ml/gdb-patches/2016-02/msg00014.html
Time to push?
> There is also a crash (regression):
>
> PR 19546 - gdb crash calling exec in the inferior
> Initial guestimate from Pedro:
> | Looks like a regression of the explicit locations work.
> Still in Pedro's court, or could Keith help?
Looks like the fix is fairly straightforward.
> Sergio - would you be able to give us a rough description of how
> good the results are in the buildbots? Anything we should be
> aware of for this release? (Thanks!)
In terms of status:
- C++ build detected a build regression: Fixed, AFAIK.
- Some regressions in Ada due to a testsuite patch
Worse case scenario, we could revert on the branch, if a simple
fix is not available (I am confident, though).
I can't see from the URLs provided what the error looks like,
but it should only affect in-tree build & testing?
So, to summarize, given how easy it can be to break C++ building,
and looking at the issues we want to solve, I can propose the following
plan:
1. Branch now, hold the pre-release;
2. Fix the issues above still pending on both master + branch;
3. Once the issues above are fixed on the branch, issue
the first pre-release.
What do you guys think?
Thanks!
--
Joel