From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115392 invoked by alias); 19 Apr 2016 15:47:25 -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 115219 invoked by uid 89); 19 Apr 2016 15:47:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=gradually, globally, five X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 19 Apr 2016 15:47:10 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.54.09012.52C46175; Tue, 19 Apr 2016 17:17:57 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.248.2; Tue, 19 Apr 2016 11:47:06 -0400 Subject: Re: [PATCH 0/1] Build GDB as a C++ program by default To: Pedro Alves , References: <1461000466-31668-1-git-send-email-palves@redhat.com> <571633C8.4060803@ericsson.com> <57163E3B.50101@redhat.com> From: Simon Marchi Message-ID: <571652FA.1010904@ericsson.com> Date: Tue, 19 Apr 2016 15:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57163E3B.50101@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00456.txt.bz2 On 16-04-19 10:18 AM, Pedro Alves wrote: > On 04/19/2016 02:34 PM, Simon Marchi wrote: >> On 16-04-18 01:27 PM, Pedro Alves wrote: >>> It's been a long ride, but GDB now builds cleanly as a C++ program on >>> most supported systems. >>> >>> There are a few host-specific files that may be missing the occasional >>> cast, but for all I know, most of the codebase has been converted and >>> builds cleanly, with no undefined behavior and no hacks. >>> >>> It's time to try building GDB with a C++ compiler by default, which is >>> what the the following trivial patch does. >>> >>> Following the discussion on the gdb@ list, this flips the default on >>> all hosts, unconditionally. > >> Does that mean that all supported hosts have been tested to build in C++? > > "all" is a bit too wide. There are simply too many to tell: > > https://sourceware.org/gdb/wiki/Systems > > I don't know whether VAX or m68k BSD build cleanly, for instance. > I don't know whether they build cleanly in C-mode, either -- I > wouldn't be surprised if several of the listed systems on that > table didn't build today. > > It sort of goes back to what you'd call "supported host". If > nobody's actively caring about such hosts, then it's just > going to happen that changes elsewhere will accidentally break > them. > > But at least we know that x86-64 NetBSD and FreeBSD build and run > in C++ mode, which I think is sufficient proxy for all BSDs, in > the sense that if something else is needed it'll probably be a > couple malloc casts here and there in the corresponding $arch-nat.c > files. > > AFAIK, all GNU/Linux ports build cleanly. > > (Except maybe Xtensa, which may need your small cast patch on > my github. Is that one still needed?). > > MinGW (w64) builds and runs cleanly for me too. > > I think the ones pending confirmation are Solaris and QNX. > > If we do find some host does trip on some big problem, then we > can always flip it back to C by default. > > Given that the request for testing with --enable-build-with-cxx > was sent five months ago, and nobody reported breakage (nor success) > on Solaris/QNX, I think we need to bite the bullet and move forward. > > We won't know unless we try. > > WDYT? Yeah, it makes sense. I thought that you wanted to go gradually, flipping to C++ by default only the hosts we have tested, so that we see which ones are remaining (and test them). But I have absolutely no objection with flipping the switch globally :).