C++

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
How to debug where a function returns using LLDB from the command line

How to debug where a function returns using LLDB from the command line

I often find myself in a situation when I want to know where a function returns. There’s no need to know the return value, as this may be the same for multiple code paths (e.g., nullptr if something went wrong). It is embarrassing, but I sometimes have put fprintf(stderr, "T1"); in my code just to follow which path the execution took. Needless to say, this behavior requires manual editing and recompilation and should be avoided if possible.

Here’s a way to elegantly debug where a function returns using lldb from the command line.

Continue reading “How to debug where a function returns using LLDB from the command line”

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
Report from February 2019 ISO WG21 C++ Standards Committee Meeting

Report from February 2019 ISO WG21 C++ Standards Committee Meeting

The February 2019 ISO C++ meeting was held in Kailua-Kona, Hawaii. As usual, Red Hat sent three of us to the meeting: I attended in the SG1 (parallelism and concurrency) group, Jonathan Wakely in Library, and Jason Merrill in the Core Working Group (see Jason’s report here). In this report, I’ll cover a few highlights of the meeting, focusing on the papers that were discussed.

Continue reading “Report from February 2019 ISO WG21 C++ Standards Committee Meeting”

Share
2 tips to make your C++ projects compile 3 times faster

2 tips to make your C++ projects compile 3 times faster

In this article, I will demonstrate how to speed up your compilation times by distributing compilation load using a distcc server container.  Specifically, I’ll show how to set up and use containers running a distcc server to distribute the compilation load over a heterogeneous cluster of nodes (development laptop, old desktop PC, and a Mac). To improve the speed of recompilation, I will use ccache.

Continue reading “2 tips to make your C++ projects compile 3 times faster”

Share
How C array sizes become part of the binary interface of a library

How C array sizes become part of the binary interface of a library

Most C compilers allow accessing an array declared extern, which has indeterminate bounds, like this:

extern int external_array[];

int
array_get (long int index)
{
  return external_array[index];
}

The definition of external_array could reside in a different translation unit and look like this:

int external_array[3] = { 1, 2, 3 };

The question is what happens if this separate definition is changed to this:

int external_array[4] = { 1, 2, 3, 4 };

Or this:

int external_array[2] = { 1, 2 };

Does either change preserve the binary interface (assuming that there is a mechanism that allows the application to determine the size of the array at run time)?

Curiously, the answer is that on many architectures, increasing the array size breaks binary interface (ABI) compatibility. Decreasing the array size may also cause compatibility problems. We’ll look more closely at ABI compatibility in this article and explain how to avoid problems.

Continue reading “How C array sizes become part of the binary interface of a library”

Share