From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31311 invoked by alias); 14 Dec 2013 00:34:24 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 31302 invoked by uid 89); 14 Dec 2013 00:34:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f49.google.com Received: from mail-wg0-f49.google.com (HELO mail-wg0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 14 Dec 2013 00:34:21 +0000 Received: by mail-wg0-f49.google.com with SMTP id x12so2505368wgg.4 for ; Fri, 13 Dec 2013 16:34:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.189.68 with SMTP id gg4mr4532256wic.46.1386981257986; Fri, 13 Dec 2013 16:34:17 -0800 (PST) Received: by 10.216.236.71 with HTTP; Fri, 13 Dec 2013 16:34:17 -0800 (PST) Date: Sat, 14 Dec 2013 00:34:00 -0000 Message-ID: Subject: [C++] System Requirements From: Ben Longbons To: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2013-12/txt/msg00019.txt.bz2 Under the assumption that most active gdb maintainers intend that future gdb releases be written in C++, I am presenting a possible plan for the conversion, based on my experience with a conversion about 1/5th the size of gdb. I have found 3.5 areas of discussion, 2.5 of which I have actually written. - System Requirements - Attack Plan -- Warning Header Proposal - Style Guide (to be written, probably not by me) A shared editing pad is available at http://piratepad.net/gdb-cxx, it will contain links to the archived mails so don't be concerned about editing what I wrote there. This thread will discuss system requirements. This is going to turn into a flamefest, but at the very minimum we *must* agree that choosing the system requirements is a trade-off between how many systems meet the requirements and how much effort it takes to do anything under those requirements. I do not ask for higher minimum requirements for no reason! Not all Turing machines are equal, even if in theory they can solve each other's problems. We have already seen the kind of trouble it takes to support old systems with Python 2.4 and also new systems with Python3. This would be much easier if the old systems requirement was Python 2.6, which can safely be coinstalled. I am glad that gdb's python support is not my problem. Unlike python, it is intrusive to upgrade the system gcc, since every application links to it. I consider that there are two different sets of requirements: - The stricter requirements for a system that active gdb developers have access to ("development mode requirements") - The looser requirements for a system to deploy ("deploy mode requirements"). As long as we regularly test the "deploy mode", it is reasonable to have different settings used if you meet the development requirements. Additionally, it is not absolutely necessary to meet the "developer mode" to develop gdb. I propose that the minimum "development requirements" is either gcc 4.6 or 4.7. The rest of this section discusses the deploy requirements. What are the current minimum deploy requirements (for gdb 7.6)? What were the minimum deploy requirements about 5 years ago (for gdb 7.0 or so)? What were the minimum deploy requirements about 10 years ago (for gdb 6.0 or so)? What were the minimum deploy requirements about 15 years ago (for gdb 4.18 or so)? gcc 3.3 is the oldest I've heard anyone tries to support. It is used by NetBSD 5.1 (2010-11-19) gcc 3.4 was the last deliberate incompatible ABI change (libstdc++.so.6). gcc 4.0 is used by older Apple systems gcc 4.1 is used by RHEL 5 gcc 4.2 is the latest gcc shipped by Apple and OpenBSD because of the GPL3 thing. However, this is becoming less important now that clang exists (but I do not think clang will necessarily support the "development requirements"). And do you *really* want free software to be help hostage by Apple? gcc 4.3 is the first release that supports some form of C++11. It is also the oldest version of gcc that I can actually get to build on my system. C++11 is a *huge* mindset change for writing C++ - it's practically a new language, when taken all together. gcc 4.3 does not support very much of C++11, but it does support some core things: - rvalue references (these are huge, both for idiom and performance) - static_assert - decltype (not quite the same as gcc's typeof extension) gcc 4.4 supports more of C++11. It is the compiler shipped with RHEL6 and Debian 6 - initializer lists (much less typing) - auto - enum class (much more safety for new code) - = default and = delete I recommend gcc 4.4 as the minimum deploy requirements. If people expect to use the latest and greatest version of gdb, they should be willing to provided a somewhat recent standards-compliant compiler. This gcc version is very widely deployed, so relatively few people will be forced to use an older version of gdb if this is chosen. If it would make the maintenance burdern lighter, it *would* be possible to declare 4.2 as the minimum requirement for the initial conversion and upgrade the requirements for the next release. However, I do not recommend this unless absolutely needed, and WE MUST NOT SUPPORT GCC 4.2 INDEFINITELY. If you disagree with my recommendation for now, what is your plain for dropping gcc 4.2? At some point, gcc 4.4 will go the way of gcc 4.2, and the requirement can be raised again. How will this be defined? I will continue listing the advantages of each newer version gcc 4.5 doesn't much to say about it, and I'm not aware of any major deployments. It does have some less-frequently-used features: - lambda functions - explicit conversion operators - local types as template arguments gcc 4.6 is the next major step towards C++11 compliance, but since it's getting closer, I keep seeing its shortcomings. But its benefits are: - nullptr (there exist compatibility libraries for this) - forward declarations of enums (unfortunately these are still buggy with debuginfo even with the most recent gcc, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 ) - constexpr (this is huge) - range-based for (much less typing; not really compatible with various macros that emulated this) - unrestricted unions (not used often, but when you need them, they're hard to do without) GCC 4.6 is also the first release that supports #pragma GCC diagnostic inside a function, which is absolutely essential in my "attack plan" and can (using _Pragma form) be #define'd out in deployment mode. gcc 4.7 is the first release that is practically compliant. Note, however, that gcc 4.7.0 and gcc 4.7.1 must be avoided at all costs due to an ABI compatibility; gcc 4.7.2 is the requirement in this case (I'm not sure which point versions are okay for the other versions). - in-class non-static data initializers - override and final (can be #define'd out for deployment and used in development) - template aliases (these are *incredibly* useful, and among many other benefits can make debugging sane since gdb doesn't support operator overloading in the print command yet) - delegating constructors - user-defined literals (useful for string-safety) gcc 4.8.1 is the first fully-compliant C++11 release. At this point, you only have to worry about bugs and DRs (I recently had some code that was illegal according to c++11 as written, but legal according to a DR). - move this (can be #define'd out for deployment) - inheriting constructors The features I listed above are the ones I use regularly in my own codebase. For a more complete list, see: http://gcc.gnu.org/projects/cxx0x.html Thanks for your time, Ben Longbons (o11c on IRC)