From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113695 invoked by alias); 11 Oct 2016 16:24: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 113678 invoked by uid 89); 11 Oct 2016 16:24:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=vintage, significantly, talks, everyday X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 16:24:20 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 61DE4B813C; Tue, 11 Oct 2016 16:24:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9BGO9CX009538; Tue, 11 Oct 2016 12:24:10 -0400 Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr To: Eli Zaretskii , Joel Brobecker References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <20161011121639.GE3813@adacore.com> <68fc02cb-59bc-012c-d1be-b5ed2076d6a5@redhat.com> <20161011144741.GF3813@adacore.com> <83insydifw.fsf@gnu.org> Cc: markus.t.metzger@intel.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 11 Oct 2016 16:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83insydifw.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00265.txt.bz2 On 10/11/2016 04:16 PM, Eli Zaretskii wrote: > IMO, requiring to build GCC as a prerequisite for building GDB is a > major setback. Building GDB is a relatively easy and straightforward > task today, even a native MS-Windows build. By contrast, building GCC > requires quite a few additional prerequisites, which will also need to > be built correctly. It also requires to configure the GCC being built > itself, which involves considering a large number of opt-in and > opt-out features, whose descriptions are not well suited for casual > users, and therefore whose consequences cannot be easily understood. Windows may be one of the hardest systems on which to build GCC. For Unix systems, it's relatively painless. It's easy to find scripts around the web that download the necessary dependencies and build gcc, all in one go. I think the GCC source tree has contrib patches for at least the downloading part. > Yes, I use GCC, of course, but I just upgraded to 5.3.0 here a few > months ago, while you seem to be already talking about 6.x. If we > start on this slippery slope, I can easily envision the requirement to > go up to 7.x very soon, exactly like switching to C++-compatible GDB > caused, within just few months, That's a misunderstanding. Full C++11 support is available in gcc 4.8 already. I believe it's easy to find binary mingw gcc's of (at least) that vintage easily, for both mingw and mingw-64. mingw talks about gcc 4.8 binaries here: http://www.mingw.org/wiki/howto_install_the_mingw_gcc_compiler_suite I don't expect anyone to _have_ to build any mingw compiler to be able to build gdb for mingw. It's just that gcc 6.x is the first version that has switched the _default_ mode for C++ to -std=gnu++14. So until someone writes a patch that make gdb's build system enable C++11 support with gcc < 6, then the C++11-only code in the gdb::unique_ptr patch that I'm proposing will only be active with gcc 6.1 onward. But really I'm not proposing to _require_ 6.x at all. > a massive rewrite of GDB in complex C++. Most of the changes have been around using std::string, destructors, and RAII, which are basic everyday C++ things. The latter two are mainly about using compiler support for things we have to manually today (make_cleanup). std::string just makes code shorter and safer, I don't see a real downside or anything complex about it. A few patches that build supporting widgets will naturally use a bit more complex C++ internally, all in the name of making _users_ of such widgets significantly simpler. This patch is one such example. These kinds of support patches naturally will need to come before we can make use of the features they add support for, so while it may appear we're going to keep adding lots of magic things, I don't think that's true. Thanks, Pedro Alves