The GNU Toolchain is a collection of programming tools produced by the GNU Project. The tools are often packaged together due to their common use for developing software applications, operating systems, and low-level software for embedded systems.
This blog is part of a regular series covering the latest changes and improvements in the components that make up this Toolchain. Apart from the announcement of new releases, however, the features described here are at the bleeding edge of software development in the tools. This does mean that it may be a while before they make it into production releases, and they might not be fully functional yet. But anyone who is interested in experimenting with them can build their own copy of the Toolchain and then try them out.
Continue reading “Sprint 2017 GNU Toolchain Update”
A few months ago, I had to write some internal GCC passes to perform static analysis on the GNU C Library (glibc). I figured I might as well write them as plugins since they were unlikely to see the light of day outside of my little sandbox. Being a long time GCC contributor, but having no experience writing plugins I thought it’d be a good way to eat our own dog food, and perhaps write about my experience.
Continue reading “Diagnosing Function Pointer Security Flaws with a GCC plugin”
In C and C++, the cases of a switch statement are in fact labels, and the switch is essentially a go to that jumps to the desired label. Since labels do not change the flow of control, one case block falls through to the following case block, unless terminated by a
break, a no return call or similar. In the example below, “
case 1” falls through to “
a = 1;
a = 2;
/* ... */
Continue reading “-Wimplicit-fallthrough in GCC 7”
GCC has a rich set of features designed to help detect many kinds of programming errors. Of particular interest are those that corrupt the memory of a running program and, in some cases, makes it vulnerable to security threats. Since 2006, GCC has provided a solution to detect and prevent a subset of buffer overflows in C and C++ programs. Although it is based on compiler technology, it’s best known under the name Fortify Source derived from the synonymous GNU C Library macro that controls the feature: _FORTIFY_SOURCE. GCC has changed and improved considerably since its 4.1 release in 2006, and with its ability to detect these sorts of errors. GCC 7, in particular, contains a number of enhancements that help detect several new kinds of programming errors in this area. This article provides a brief overview of these new features. For a comprehensive list of all major improvements in GCC 7, please see GCC 7 Changes document.
Continue reading “Memory Error Detection Using GCC”
The next release of the GNU Compiler Collection, GCC 7, is fast approaching, so in this post, I’m going to talk about work I’ve done to make GCC more reliable
Continue reading “Testing… Testing… GCC”
This article describes the steps required to add buffer overflow protection to string functions. As a real-world example, we use the
strlcpy function, which is implemented in the libbsd library on some GNU/Linux systems.
This kind of buffer overflow protection uses a GNU Compiler Collection (GCC) feature for array size tracking (“source fortification”), accessed through the
__builtin_object_size GCC built-in function. In general, these checks are added in a size-checking wrapper function around the original (wrapped) function, which is
strlcpy in our example.
Continue reading “Adding buffer overflow detection to string functions”
Today, Red Hat announced the beta availability of Red Hat Developer Toolset 6.0 Beta. Accessible through the Red Hat Developer Program and related Red Hat Enterprise Linux subscriptions, including the no-cost Red Hat Enterprise Linux Developer subscription, Red Hat Developer Toolset enables developers to compile applications once and deploy across multiple versions of Red Hat Enterprise Linux.
Updated components within Red Hat Developer Toolset 6.0 Beta include versions of:
Continue reading “New Red Hat Developer Toolset 6 now in beta”
GDB relies on
libcc1‘s GCC and GDB plugins to implement the “
compile code” feature, now extended to support the C++ language.
Compile and Execute machinery enables GDB users to compile and execute code snippets within the context of an existing process. This allows users to perform inspection and modification of the program state using the target language well beyond the feature set historically exposed by symbolic debuggers. Almost anything that can be expressed in C, and now also in C++, can be compiled, loaded into the running program, and executed on the spot! It is envisioned that this machinery may also be used in the future to speed up conditional breakpoints, and as a foundation for more advanced features such as “Edit and Continue”.
libcc1 module offers plugins for GDB and GCC that allow GDB to start GCC to compile a user-supplied code snippet. The plugins combine GDB and GCC into a single multi-process program. Through the plugins, GCC can query GDB about the meaning, in the target program, of names encountered in the snippet, and GDB can incrementally inform GCC about variables, functions, types and other constructs present in the program.
Continue reading “C++ support in libcc1: A comprehensive update”
The recent WG21 meeting in Oulu, Finland, was an especially busy one for the Library Working Group. Every day was spent working through the list of proposals intended for inclusion in C++17, and we also had three “evening” sessions that ran well past the evening (until nearly midnight, although the sun was still up to trick us into working late).
This post describes what I think are the most important library features that were reviewed and approved for inclusion in C++17. As usual, see Jason and Torvald’s posts for news from the Core and Parallelism & Concurrency groups. As Jason explained, the main goal of the Oulu meeting was to finalize the content of the Committee Draft (CD) for C++17. The Library Working Group started the meeting with a huge number of papers intended for inclusion in the CD, and we managed to complete the review of almost all of them.
Continue reading “Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Library”
It was quite a trek to get to Oulu, Finland for the June 2016 C++ Standards Committee meeting, but we were warmly received and the meeting went well once we arrived. We had very pleasant weather most of the week, and it was fun to experience the midnight sun, even though it played havoc with my sleep schedule.
The main order of business at this meeting was to vote on a first Committee Draft (CD) of the (expected) C++17 standard, ideally with as much as possible of the work that has been moving through the pipeline. The Core and especially the Library working groups were very effective at moving through their workload of papers at this meeting: Core ended the week with no papers left to review, and Library got through ~50 papers and had only two left at the end.
As usual, the committee divided into multiple working groups: the primary groups that met throughout the week are Core language, language Evolution, Library, Library Evolution, and Parallelism/Concurrency (SG1). Also as usual, I spent the week in the Core language working group.
In my report on the Jacksonville C++ Meeting last February, I described various proposals that were working through the committee. Of the core language features I listed there as expected or hoped to make it into C++17 at this meeting, almost all did. Note that as of this writing the final revisions of the adopted papers have not been posted publicly yet, but the links should adjust when they are.
Continue reading “Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Core Language”