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”
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:
The key principles for code generation to prevent a stack clash attack are:
Continue reading “Stack clash mitigation in GCC, Part 3”
When examining Linux firewall performance, there is a second aspect to packet processing—namely, the cost of firewall setup manipulations. In a world of containers, distinct network nodes spawn quickly enough for firewall ruleset adjustment delay to become a significant factor. At the same time, rulesets tend to become huge given the number of containers even a moderately specced server might host.
In the past, considerable effort was put into legacy
iptables to speed up the handling of large rulesets. With the recent push upstream and downstream to establish
iptables-nft as the standard variant, a reassessment of this quality is in order. To see how bad things really are, I created a bunch of benchmarks to run with both variants and compare the results.
Continue reading “Optimizing iptables-nft large ruleset performance in user space”
The Time Zone Database (
tzdata) provides Red Hat Enterprise Linux (RHEL) with data that is specific to the local time zone. Applications in the Linux operating system use this data for various purposes. For instance, the GNU C Library (
tzdata to ensure APIs such as
strftime() work correctly, while applications such as
/usr/bin/date use it to print the local date.
tzdata package contains data files documenting both current and historic transitions for various time zones around the world. This data represents changes required by local government bodies or by time zone boundary changes, as well as changes to coordinated universal time (UTC) offsets and daylight saving time (DST).
This article is a quick update about changes to the
tzdata package in 2019, as well as possible time zone changes that we are monitoring for package updates in 2020.
Continue reading “What’s new with tzdata: The time zone database for Red Hat Enterprise Linux”
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”