I work at Red Hat on GCC, the GNU Compiler Collection. For the next major release of GCC, GCC 10, I’ve been implementing a new
-fanalyzer option: A static analysis pass to identify various problems at compile-time, rather than at runtime.
My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary). Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees—because it is the compiler.
Continue reading “Static analysis in GCC 10”
A new version of the OpenMP standard, 5.0, was released in November 2018 and brings several new constructs to the users. OpenMP is an API consisting of compiler directives and library routines for high-level parallelism in C, C++, and Fortran programs. The upcoming version of GCC adds support for some parts of this newest version of the standard.
This article highlights some of the latest features, changes, and “gotchas” to look for in the OpenMP standard.
Continue reading “What’s new in OpenMP 5.0”
As part of the GCC developers‘ on-demand range work for GCC 10, I’ve been playing with improving the backward jump threader so it can thread paths that are range-dependent. This, in turn, had me looking at the jump threader, which is a part of the compiler I’ve been carefully avoiding for years. If, like me, you’re curious about compiler optimizations, but are jump-threading-agnostic, perhaps you’ll be interested in this short introduction.
Continue reading “A gentle introduction to jump threading optimizations”
I work at Red Hat on GCC, the GNU Compiler Collection, and I spent most of the past year making GCC easier to use. Let’s look at C and C++ improvements that will be in the next major release of GCC, GCC 9.
Continue reading “Usability improvements in GCC 9”
Continuing in the effort to detect common programming errors, the just-released GCC 8 contains a number of new warnings as well as enhancements to existing checkers to help find non-obvious bugs in C and C++ code. This article focuses on those that deal with inadvertent string truncation and discusses some of the approaches for avoiding the underlying problems. If you haven’t read it, you might also want to read David Malcolm’s article Usability improvements in GCC 8.
To use GCC 8 on RHEL, see How to install GCC 8 and Clang/LLVM 6 on Red Hat Enterprise Linux 7. GCC 8 is the default compiler in Red Hat Enterprise Linux 8 Beta.
Why Is String Truncation a Problem?
It is well-known why buffer overflow is dangerous: writing past the end of an object can overwrite data in adjacent storage, resulting in data corruption. In the most benign cases, the corruption can simply lead to incorrect behavior of the program. If the adjacent data is an address in the executable text segment, the corruption may be exploitable to gain control of the affected process, which can lead to a security vulnerability. (See CWE-119 for more on buffer overflow.)
Continue reading “Detecting String Truncation with GCC 8”
Did you know that when you compile your C or C++ programs, GCC will not enable all exceptions by default? Do you know which build flags you need to specify in order to obtain the same level of security hardening that GNU/Linux distributions use (such as Red Hat Enterprise Linux and Fedora)? This article walks through a list of recommended build flags.
The GNU-based toolchain in Red Hat Enterprise Linux and Fedora (consisting of GCC programs such as
g++, and Binutils programs such as
ld) are very close to upstream defaults in terms of build flags. For historical reasons, the GCC and Binutils upstream projects do not enable optimization or any security hardening by default. While some aspects of the default settings can be changed when building GCC and Binutils from source, the toolchain we supply in our RPM builds does not do this. We only align the architecture selection to the minimum architecture level required by the distribution.
Consequently, developers need to pay attention to build flags, and manage them according to the needs of their project for optimization, level of warning and error detection, and security hardening.
Continue reading “Recommended compiler and linker flags for GCC”
I work at Red Hat on GCC, the GNU Compiler Collection.
My main focus for the last year has been on making GCC easier to use, so I thought I’d write about some of the C and C++ improvements I’ve made that are in the next major release of GCC, GCC 8. You can easily install GCC 8 on Red Hat Enterprise Linux 6 and 7 using Red Hat Developer Toolset (DTS). GCC 8 is the default compiler in Red Hat Enterprise Linux 8 Beta. GCC 8 is also available in Fedora 28 and later.
Continue reading “Usability improvements in GCC 8”
GCC has a rich set of features designed to help detect many kinds of programming errors. Of particular interest are those that corrupt the memory of a running program and, in some cases, makes it vulnerable to security threats. Since 2006, GCC has provided a solution to detect and prevent a subset of buffer overflows in C and C++ programs. Although it is based on compiler technology, it’s best known under the name Fortify Source derived from the synonymous GNU C Library macro that controls the feature: _FORTIFY_SOURCE. GCC has changed and improved considerably since its 4.1 release in 2006, and with its ability to detect these sorts of errors. GCC 7, in particular, contains a number of enhancements that help detect several new kinds of programming errors in this area. This article provides a brief overview of these new features. For a comprehensive list of all major improvements in GCC 7, please see GCC 7 Changes document.
Continue reading “Memory Error Detection Using GCC”
The next release of the GNU Compiler Collection, GCC 7, is fast approaching, so in this post, I’m going to talk about work I’ve done to make GCC more reliable
Continue reading “Testing… Testing… GCC”
OpenJDK is the premier open source Java implementation. The OpenJDK project provides the code used to build Red Hat’s Java releases for Fedora and RHEL and the Java releases used on most other Linux distributions. It also forms the basis of Oracle’s proprietary Java binary releases.
The Red Hat OpenJDK team has been working for some time now, along with organizations like the London Java Community (LJC) and some of our academic partners (e.g. Glasgow & Manchester) to encourage researchers and developers to dive into the innards of OpenJDK’s Java Virtual Machine (JVM) and see how it actually works. One reason is the entirely selfish one that we would like to enlarge the community of potential contributors to the OpenJDK project. Another is that we think it is no bad thing for Java developers, as indeed for any developers, to understand the tools they are using at a deeper level and appreciate how a well designed tool shields them from having to manage some of the more complex aspects of the runtime environment in which their programs execute.
Continue reading “What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK”