This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: branching for GDB 7.11 soon? (possibly Wed)


On 02/09/2016 11:56 AM, Joel Brobecker wrote:
> 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.

I took a quick look and it looks fine to me too.

> 
>> 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?

Done.

> 
>> 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.

Yes, fixed.

> 
> - 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?

Sounds good to me.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]