C++

New C++ features in GCC 10

New C++ features in GCC 10

The GNU Compiler Collection (GCC) 10.1 was released in May 2020. Like every other GCC release, this version brought many additions, improvements, bug fixes, and new features. Fedora 32 already ships GCC 10 as the system compiler, but it’s also possible to try GCC 10 on other platforms (see godbolt.org, for example). Red Hat Enterprise Linux (RHEL) users will get GCC 10 in the Red Hat Developer Toolset (RHEL 7), or the Red Hat GCC Toolset (RHEL 8).

Continue reading New C++ features in GCC 10

Share
The joys and perils of aliasing in C and C++, Part 2

The joys and perils of aliasing in C and C++, Part 2

In the previous article, I discussed the benefits of C and C++ language restrictions in optimized code. In this second half, I present a variety of programming language exemptions and compiler extensions that developers can use to get around aliasing restrictions more or less safely. I will also discuss the common pitfalls of aliasing, both resulting from the extensions as well as from misuses of standard language constructs, and illustrate common problems these pitfalls might cause.

Continue reading “The joys and perils of aliasing in C and C++, Part 2”

Share
The joys and perils of C and C++ aliasing, Part 1

The joys and perils of C and C++ aliasing, Part 1

In C, C++, and some other programming languages, the term aliasing refers to a situation where two different expressions or symbols refer to the same object. When references access that object in different ways—as both reads and stores—there are consequences for the order in which these mixed accesses can happen. The value that is stored first is expected to be read by the subsequent access. In many instances, aliasing is harmless: It is common, safe, and usually optimally efficient to use two pointers of the same type to read, and even to write to the same object. But in some cases, using aliasing symbols for mixed accesses is less benign, and can adversely affect the correctness or efficiency of your code.

Although there are quite a few articles on this subject, most tend to focus on the rules and requirements outlined in the standards (such as the strict aliasing rule). In this article, I focus on the details of the C and C++ language restrictions, their challenges and pitfalls, and examples demonstrating the restrictions’ beneficial effects in optimized code. In Part 2, I will present exemptions from aliasing, which can help you get around the restrictions more or less safely. I also consider some of the common pitfalls of aliasing and mixed accesses, and the actual problems these pitfalls might cause.

Continue reading “The joys and perils of C and C++ aliasing, Part 1”

Share
Red Hat Software Collections 3.5 brings updates for Red Hat Enterprise Linux 7

Red Hat Software Collections 3.5 brings updates for Red Hat Enterprise Linux 7

Red Hat Software Collections 3.5 and Red Hat Developer Toolset 9.1 are now available for Red Hat Enterprise Linux 7. Here’s what that means for developers.

Red Hat Software Collections (RHSCL) is how we distribute the latest stable versions of various runtimes and languages through Red Hat Enterprise Linux (RHEL) 7, with some components available in RHEL 6. RHSCL also contains the Red Hat Developer Toolset, which is the set of tools we curate for C/C++ and Fortran. These components are supported for up to five years, which helps you build apps that have a long lifecycle as well.

Continue reading “Red Hat Software Collections 3.5 brings updates for Red Hat Enterprise Linux 7”

Share
Stack clash mitigation in GCC, Part 3

Stack clash mitigation in GCC, Part 3

In previous posts, Stack Clash Mitigation in GCC — Background and Stack Clash mitigation in GCC: Why -fstack-check is not the answer, I hopefully showed the basics of how stack clash attacks are structured and why GCC’s existing -fstack-check mechanism is insufficient for protection.

So, what should we do? Clearly we want something similar to -fstack-check, but without the fundamental problems. Enter a new option: -fstack-clash-protection.

The key principles for code generation to prevent a stack clash attack are:

Continue reading “Stack clash mitigation in GCC, Part 3”

Share
Report from the February 2020 ISO C++ meeting (Core Language Working Group)

Report from the February 2020 ISO C++ meeting (Core Language Working Group)

The first International Organization for Standardization (ISO) C++ meeting of 2020 happened in Prague, Czechia. It was our first time meeting in Prague, though I’ve been there a few times for the GNU Tools Cauldron. Two of us from Red Hat attended: Jonathan Wakely serves on the ISO C++ Standards Committee Library Working Group (LWG), and I am part of the Core Language Working Group (CWG). (You can see the ISO C++ committee structure here.)

Continue reading Report from the February 2020 ISO C++ meeting (Core Language Working Group)

Share
How to write an ABI compliance checker using Libabigail

How to write an ABI compliance checker using Libabigail

I’ve previously written about the challenges of ensuring forward compatibility for application binary interfaces (ABIs) exposed by native shared libraries. This article introduces the other side of the equation: How to verify ABI backward compatibility for upstream projects.

If you’ve read my previous article, you’ve already been introduced to Libabigail, a static-code analysis and instrumentation library for constructing, manipulating, serializing, and de-serializing ABI-relevant artifacts.

In this article, I’ll show you how to build a Python-based checker that uses Libabigail to verify the backward compatibility of ABIs in a shared library. For this case, we’ll focus on ABIs for shared libraries in the executable and linkable format (ELF) binary format that runs on Linux-based operating systems.

Continue reading “How to write an ABI compliance checker using Libabigail”

Share
Toward _FORTIFY_SOURCE parity between Clang and GCC

Toward _FORTIFY_SOURCE parity between Clang and GCC

GCC combined with glibc can detect instances of buffer overflow by standard C library functions. When a user passes the -D_FORTIFY_SOURCE={1,2} preprocessor flag and an optimization level greater or equal to -O1, an alternate, fortified implementation of the function is used when calling, say, strcpy. Depending on the function and its inputs, this behavior may result in a compile-time error, or a runtime error triggered upon execution. (For more info on this feature, there’s an excellent blog post here on the subject).

Continue reading Toward _FORTIFY_SOURCE parity between Clang and GCC

Share
Deploying debuginfod servers for your developers

Deploying debuginfod servers for your developers

In an earlier article, Aaron Merey introduced the new elfutils debuginfo-server daemon. With this software now integrated and released into elfutils 0.178 and coming to distros near you, it’s time to consider why and how to set up such a service for yourself and your team.

Recall that debuginfod exists to distribute ELF or DWARF debugging information, plus associated source code, for a collection of binaries. If you need to run a debugger like gdb, a trace or probe tool like perf or systemtap, binary analysis tools like binutils or pahole, or binary rewriting libraries like dyninst, you will eventually need debuginfo that matches your binaries. The debuginfod client support in these tools enables a fast, transparent way of fetching this data on the fly, without ever having to stop, change to root, run all of the right yum debuginfo-install commands, and try again. Debuginfo lets you debug anywhere, anytime.

We hope this opening addresses the “why.” Now, onto the “how.”

Continue reading “Deploying debuginfod servers for your developers”

Share
Report from July 2019 ISO C++ Standards Committee Meeting (Concurrency and Parallelism Study Group)

Report from July 2019 ISO C++ Standards Committee Meeting (Concurrency and Parallelism Study Group)

The summer 2019 WG21 C++ Committee meeting was held in Cologne, Germany during the week of July 13. As usual,
Red Hat sent three representatives, Jason Merrill in the Core Working Group (CWG), Jonathan Wakely in the Library Working Group (LWG), and myself in the Concurrency and Parallelism Study Group (SG1). This rather late report covers the Cologne SG1 session and looks ahead to some revised papers from that meeting, which are scheduled for the fall meeting in Belfast, Northern Ireland, for the first week of November 2019.

Continue reading “Report from July 2019 ISO C++ Standards Committee Meeting (Concurrency and Parallelism Study Group)”

Share