gcc

Static analysis in GCC 10

Static analysis in GCC 10

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”

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
An upside-down approach to GCC optimizations

An upside-down approach to GCC optimizations

Many traditional optimizations in the compiler work from a top-down approach, which starts at the beginning of the program and works toward the bottom. This allows the optimization to see the definition of something before any uses of it, which simplifies most evaluations. It’s also the natural way we process things. In this article, we’ll look at a different approach and a new project called Ranger, which attempts to turn this problem upside down.

Continue reading “An upside-down approach to GCC optimizations”

Share
Python wheels, AI/ML, and ABI compatibility

Python wheels, AI/ML, and ABI compatibility

Python has become a popular programming language in the AI/ML world. Projects like TensorFlow and PyTorch have Python bindings as the primary interface used by data scientists to write machine learning code. However, distributing AI/ML-related Python packages and ensuring application binary interface (ABI) compatibility between various Python packages and system libraries presents a unique set of challenges.

The manylinux standard (e.g., manylinux2014) for Python wheels provides a practical solution to these challenges, but it also introduces new challenges that the Python community and developers need to consider. Before we delve into these additional challenges, we’ll briefly look at the Python ecosystem for packaging and distribution.

Continue reading “Python wheels, AI/ML, and ABI compatibility”

Share
Report from the February 2019 ISO C++ meeting (Library)

Report from the February 2019 ISO C++ meeting (Library)

Back in February, I attended the WG21 C++ standards committee meeting in rainy Kona, Hawaii (yes, it rained most of the week). This report is so late that we’re now preparing for the next meeting, which will take place mid-July in Cologne.

As usual, I spent the majority of my time in the Library Working Group (for LWG; for details on the various Working Groups and Study Groups see Standard C++: The Committee). The purpose of the LWG is to formalize the specification of the C++ Standard Library, i.e. the second “half” of the C++ standard (although in terms of page count it’s closer to three quarters than half). With a new C++20 standard on the horizon, and lots of new features that people want added to the standard library, the LWG has been very busy trying to process the backlog of new proposals forwarded by the Library Evolution Working Group (LEWG).

Continue reading “Report from the February 2019 ISO C++ meeting (Library)”

Share
Developer Toolset 8.1 and GCC 8.3 now available for Red Hat Enterprise Linux  7

Developer Toolset 8.1 and GCC 8.3 now available for Red Hat Enterprise Linux 7

Red Hat Developer Toolset delivers GCC, GDB, and a set of complementary development tools for Red Hat Enterprise Linux via two release trains per year. We are pleased to share that Developer Toolset 8.1 with GCC 8.3 is now available and supported on Red Hat Enterprise Linux 7.

Continue reading “Developer Toolset 8.1 and GCC 8.3 now available for Red Hat Enterprise Linux 7”

Share
Stack Clash mitigation in GCC: Why -fstack-check is not the answer

Stack Clash mitigation in GCC: Why -fstack-check is not the answer

In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.

GCC has a capability (-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how -fstack-check works and why it is insufficient for mitigating Stack Clash attacks.

Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”

Share
How to use the Linux perf tool to count software events

How to use the Linux perf tool to count software events

The Linux perf tool was originally written to allow access to the performance monitoring hardware that counts hardware events, such as instructions executed, processor cycles, and cache misses. However, it can also be used to count software events, which can be useful in gauging how frequently some part of the system software is executed.

Recently someone at Red Hat asked whether there was a way to get a count of system calls being executed on the system. The kernel has a predefined software trace point, raw_syscalls:sys_enter, which collects that exact information; it counts each time a system call is made. To use the trace point events, the perf command needs to be run as root.

Continue reading “How to use the Linux perf tool to count software events”

Share
Implicit function declarations: flex’s use of “reallocarray”

Implicit function declarations: flex’s use of “reallocarray”

Several months ago, I took over the maintenance of the flex package in Fedora and decided to kick the tires by rebasing the package in Fedora Rawhide. I downloaded and hashed the latest tarball at the time, flex-2.6.4, tweaked the spec file, and fired up a local build. Unfortunately, it failed with a SIGSEGV at build time:

./stage1flex -o stage1scan.c ./scan.l
make[2]: *** [Makefile:1695: stage1scan.c] Segmentation fault (core dumped)

Some debugging with gdb led me to the conclusion that the segmentation fault was the result of a block of memory returned from the reallocarray function being written to during flex initialization.  In this article, I’ll describe the issue further and explain changes made to address it.

Continue reading “Implicit function declarations: flex’s use of “reallocarray””

Share
Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset 8.1 Beta now available

Red Hat Developer Toolset augments Red Hat Enterprise Linux with the latest, stable versions of GCC that install alongside the original base version. This version of Red Hat Developer Toolset 8.1 Beta includes the following new components:

  • GCC 8.2.1
  • GDB 8.2
  • binutils 2.30
  • elfutils 0.176
  • Valgrind 3.14.0

This Beta release is supported on Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 for AMD64 and Intel 64 architectures. It also supports the following architectures on Red Hat Enterprise Linux 7:  64-bit ARM, big- and little-endian variants of IBM POWER (), and IBM Z. See below for more information about each updated component.

Continue reading “Red Hat Developer Toolset 8.1 Beta now available”

Share