XDP (eXpress Data Path) is a powerful new networking feature in Linux that enables high-performance programmable access to networking packets before they enter the networking stack. But XDP has a high learning curve. Many developers have written introduction blogs for this feature, such as Paolo Abeni’s Achieving high-performance, low-latency networking with XDP: Part I and Toke’s Using the eXpress Data Path (XDP) in Red Hat Enterprise Linux 8.
Continue reading Get started with XDP
I work at Red Hat on the GNU Compiler Collection (GCC). In GCC 10, I added the new
-fanalyzer option, a static analysis pass for identifying various problems at compile-time, rather than at runtime. The initial implementation was aimed at early adopters, who found a few bugs, including a security vulnerability: CVE-2020-1967. Bernd Edlinger, who discovered the issue, had to wade through many false positives accompanying the real issue. Other users also managed to get the analyzer to crash on their code.
I’ve been rewriting the analyzer to address these issues in the next major release, GCC 11. In this article, I describe the steps I’m taking to reduce the number of false positives and make this static analysis tool more robust.
Continue reading “Static analysis updates in GCC 11”
In my previous article about nsswitch.conf I talked about how simple, perhaps too simple, this config file is to use. What I didn’t cover then was how simplistic its internal implementation is. Specifically, an application only loads this file once—the first time it’s needed.
Continue reading Coming in glibc 2.33: Reloadable nsswitch.conf
One of the most important early decisions when building a Linux distribution is the scope of supported hardware. The distribution’s default compiler flags are significant for hardware-platform compatibility. Programs that use newer CPU instructions might not run on older CPUs. In this article, I discuss a new approach to building the x86-64 variant of Red Hat Enterprise Linux (RHEL) 9 and share Red Hat’s recommendation for that build.
Continue reading Building Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level
When moving an application that you’ve compiled on Red Hat Enterprise Linux (RHEL) 7 to RHEL 8, you will likely encounter issues due to changes in the application binary interface (ABI). The ABI describes the low-level binary interface between an application and its operating environment. This interface requires tools such as compilers and linkers, as well as the produced runtime libraries and the operating system itself, to agree upon the following:
Continue reading Migrating C and C++ applications from Red Hat Enterprise Linux version 7 to version 8
Java holds its dominating position in enterprise middleware for good reasons; however, describing anything in Java as “micro” requires a generous interpretation. It isn’t unusual to find Java-based microservices that need half a gigabyte of RAM to provide modest functionality at a modest load. The trend toward serverless architectures, where services are started and stopped according to demand, does little to improve the situation.
It has recently become possible to compile Java to a native executable using tools like GraalVM. This technique, coupled with an optimized Java runtime like Quarkus, tames Java’s resource consumption to some extent.
Nevertheless, we should not lose sight of programming languages that were designed from the start to compile to native code, with little to no runtime overhead. Languages like Rust and Go have become popular, and justifiably so. For optimal runtime resource usage and millisecond startup times, though, it remains hard to beat C.
Continue reading “Developing micro-microservices in C on Red Hat OpenShift”
The Python interpreter shipped with Red Hat Enterprise Linux (RHEL) 8 is version 3.6, which was released in 2016. While Red Hat is committed to supporting the Python 3.6 interpreter for the lifetime of Red Hat Enterprise Linux 8, it is becoming a bit old for some use cases.
Continue reading Red Hat Enterprise Linux 8.2 brings faster Python 3.8 run speeds
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”
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”
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”