Recommended compiler and linker flags for GCC

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 gcc, g++, and Binutils programs such as as and 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”

Share

Memory Error Detection Using GCC

Introduction

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”

Share

What Lies Beneath: A tour of the dark gritty underbelly of OpenJDK

java icon 240 × 171OpenJDK 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”

Share

Array allocation in C++

This technical article covers a subtlety in C++ array allocation and how we changed the GNU C++ compiler to deal with it properly. When a programmer writes

T *p = new T[3];

the C++ compiler allocates room for at least three copies of objects of type T on the heap. These objects require 3 * sizeof(T) bytes. For this example, assume sizeof(T) is 12, then it is straightforward to allocate 36 bytes (for example, using malloc). But what happens if the array length is 3937053355 (or 16909515400900422315 on a 64-bit architecture)? Then 47244640260 bytes are required. This number cannot be expressed in 32-bits, so if 32-bit arithmetic is used to perform the multiplication, the result is a mere 4. Unless special care is taken, a C++ implementation will provide a pointer to a heap area that is much too small for holding the requested number of objects (4 bytes instead of 47244640260 bytes).

Continue reading “Array allocation in C++”

Share