From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129031 invoked by alias); 24 Dec 2019 12:24:01 -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 129013 invoked by uid 89); 24 Dec 2019 12:24:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f44.google.com Received: from mail-wm1-f44.google.com (HELO mail-wm1-f44.google.com) (209.85.128.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Dec 2019 12:23:58 +0000 Received: by mail-wm1-f44.google.com with SMTP id q9so726313wmj.5 for ; Tue, 24 Dec 2019 04:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=SeTIX+zCfTuefw4RitUe4ASqQchOHC77Tp+1le1K7M8=; b=e5MJKqGGzWlStjZcfcwdZVilrvFOaYgGJlXzsmZWEMxpFTUjYEs7aTapmWC30h9FZw u1ksPzB3VHOrVNCWFSGQSvcnADJPrqCK8KLxhOmSIp16eRLzukrMCbErvBKhu6U58XZa VgilpLlTFChIwbC9ujhhZBIJQgZDpHhz4NJhn9YeYqYIt34upE6k7u7YSmwMlDVSRwCg a5iXf+0wGQxPS9XozbZE7Cd/qBhrWfEd9zxtOQyOVvWwkScJ9oVZLGwEQvKsV9B96+Yu gV0Aijih5XXOqvMIVzOM3GtidhSd6Vch8rNtzKmTZ9Flx48ONl+OKnhj7WCD3hJf/8UC J2xA== Return-Path: Received: from localhost (host86-186-80-236.range86-186.btcentralplus.com. [86.186.80.236]) by smtp.gmail.com with ESMTPSA id x16sm2485244wmk.35.2019.12.24.04.23.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Dec 2019 04:23:55 -0800 (PST) Date: Tue, 24 Dec 2019 12:24:00 -0000 From: Andrew Burgess To: Joel Brobecker Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: GDB 9.1 release 2019-12-23 update Message-ID: <20191224122354.GH3865@embecosm.com> References: <20191223093031.GE11677@adacore.com> <835zi7xh7o.fsf@gnu.org> <20191224034652.GA25918@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191224034652.GA25918@adacore.com> X-Fortune: That that is is that that is not is not. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00993.txt.bz2 * Joel Brobecker [2019-12-24 07:46:52 +0400]: > > > So, as far as I know, the only issues that are still open are > > > the issues that Eli found with the pre-release. > > > > Sorry about that. > > Not your fault! > > > > - [EliZ] readline/colors.c build failure > > > > > > Caused by S_IXGRP and S_IXOTH not being defined on MinGW. > > > Patch sent to readline, and should be applied to our local > > > tree soon. > > > > Will do soon. > > Nice. > > > > - [EliZ] configure warning when checking for pthread-config > > > > > > Problem understood, but EliZ blocked because he doesn't have > > > the correct auto-tools version. Hopefully building those > > > from source is an option. > > > > I believe this was already fixed. > > Double Nice. > > > > - [Eliz] libtcf fails to build on MinGW > > > https://sourceware.org/bugzilla/show_bug.cgi?id=25155 > > > > > > Problem reported to binutils on Dec 17th, but so far > > > no answer as far as I can tell. > > > https://sourceware.org/ml/binutils/2019-12/msg00277.html > > > > > > If we don't get an answer after the end of year holidays, > > > I suggest we send in a patch, which will likely help move > > > things along. From Eli's message on bugzilla, we shouldn't > > > be far from having one. > > > > I already have a patch, so I can apply it whenever you say so. > > Let's try to have it reviewed by the binutils folks if we can. > It seems relatively straightforward, but I tend to avoid fixing > things in a branch before it gets fixed in master. Maybe send > the patch to binutils with an RFA? If that doesn't work, then > we'll consider the option of just patching our branch so > we can release. > > > > Are there other issues that I may have missed for which we should > > > wait until we can release GDB 9.1? > > > > What about the compilation warning in record-btrace.c I reported in > > https://sourceware.org/ml/gdb-patches/2019-12/msg00706.html? Do we > > want to fix it? > > We can, but (IMO) not super critical. FWIW, I don't get the warning > when buidling on GNU/Linux. I can reproduce the warning on GNU/Linux, but it only crops up at some optimisation levels, -O0 doesn't warn for me, while -O1 and -O2 do. I've tested with GCC 8.3, 9.2, and a 10.??. This is all on a Fedora 27 system (yes, I really should update). That said, I had a look at the code in question and I suspect the warning is incorrect, unless I'm missing some clever C++ corner case, which is quite possible. So, we have one of these: gdb::optional asm_list; The "uninitialised" variable is a member of the ui_out_emit_list, being used during its destructor. But the destructor is only called if the ui_out_emit_list is initialised, which requires the member variable to be set.... Currently I would be happy to release with the warning present. Thanks, Andrew