From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69382 invoked by alias); 11 Oct 2016 17:15:03 -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 69217 invoked by uid 89); 11 Oct 2016 17:15:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=hacking, Hx-languages-length:4198, optout X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 17:14:51 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1bu0dc-0004hC-9j from Luis_Gustavo@mentor.com ; Tue, 11 Oct 2016 10:14:48 -0700 Received: from [172.30.8.195] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Oct 2016 10:14:43 -0700 Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr 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> To: Pedro Alves , Eli Zaretskii , Joel Brobecker CC: , From: Luis Machado Reply-To: Luis Machado Message-ID: <4bdcd06e-1324-db5b-2c49-941a7dcfaed6@codesourcery.com> Date: Tue, 11 Oct 2016 17:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00269.txt.bz2 On 10/11/2016 11:24 AM, Pedro Alves wrote: > 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. Maybe this should be discussed in gdb@, but... Some of Eli's points resonate with me. It seems we just recently got the C++ compatibility sorted out and we're quickly moving on to try and C++-ify what we can with no clear goal, priority list or high level picture. So, just to make it C++ now that we require a C++ compiler. I thought i'd throw this question out there. Wasn't the goal of moving to C++ to help the implementation of features that were hard to implement with C like some of the Fortran bits with dynamic arrays? Also improve the poor experience with C++ debugging? I was asking myself, this week, if GCC went through such a big C++-ification effort when they moved away from C. Another point i worry about is that we will switch the focus, at least for a few months, to C++-ifying things "just because" instead of taking the opportunity of such a big change to review bits of GDB that need to be redesigned/dropped/go away. Maybe just converting existing things to C++ is not the right answer, even though it is fun to do and will provide enough hacking fun? I have another point about whether this will stimulate more contributors to send patches to GDB or not, but that's enough rambling for now. :-)