From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77632 invoked by alias); 24 Aug 2018 18:35:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 77610 invoked by uid 89); 24 Aug 2018 18:35:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=black, flipped, blocker X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Aug 2018 18:35:31 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 66430EFDD3; Fri, 24 Aug 2018 18:35:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 98C0D2026D6D; Fri, 24 Aug 2018 18:35:29 +0000 (UTC) Subject: Re: GDB 8.2 release 2018-08-21 status update To: Kevin Buettner , gdb-patches@sourceware.org References: <20180821175136.GA3365@adacore.com> <0e24ffbeb9706f75c53d3fdcfea3decb@polymtl.ca> <20180823154138.66be5572@pinnacle.lan> Cc: Simon Marchi , Joel Brobecker From: Pedro Alves Message-ID: Date: Fri, 24 Aug 2018 18:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180823154138.66be5572@pinnacle.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00597.txt.bz2 On 08/23/2018 11:41 PM, Kevin Buettner wrote: > Simon Marchi wrote: >> So from my point of view, it would be fine to include it in 8.2. I'm >> just wondering though why this was considered as a blocker for 8.2 in >> the first place. It's not really a regression, it's more like a new >> feature. Was it to make sure we get the feature to users faster, before >> the new gcc that emits code like this by default starts to spread too >> much? Yeah, the main issue here is that nowadays -freorder-blocks-and-partition is on by default in GCC (I believe the switch was flipped in GCC 8?), which means users will run into this problem more frequently going forward. While technically it's not a GDB regression (you can always run into this if you build your program with -freorder-blocks-and-partition explicitly), from the perspective of end users looking at the toolchain as whole black box, it's a toolchain regression (defaults no longer work). I'd support putting the series in GDB 8.2. Unless I'm wrong that -freorder-blocks-and-partition is on by default in GCC 8 already? > > According to Thomas Koenig, from GCC bug 84550: > > With gdb 8.0.1, stepping through functions after breakpoints is > often broken. This makes it hard to debug gcc itself. > > The non-contiguous address ranges patches _might_ make it easier for > gcc developers to debug gcc. While I'm all for helping our GCC hacker friends, I'm more concerned with the general users, since presumably GCC developers would have no big trouble building a new GDB from sources. Thanks, Pedro Alves