Memory Error Detection Using GCC

Introduction

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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Testing… Testing… GCC

The next release of the GNU Compiler CollectionGCC 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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Adding buffer overflow detection to string functions

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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

New Red Hat Developer Toolset 6 now in beta

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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

C++ support in libcc1: A comprehensive update

GDB relies on libcc1‘s GCC and GDB plugins to implement the “compile code” feature, now extended to support the C++ language.

The 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”.

The 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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Library

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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Red Hat at the ISO C++ Standards Meeting (June 2016, Oulu): Core Language

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”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Red Hat at the ISO C++ Standards Meeting (March 2016): Library

Earlier this year I attended the WG21 C++ standards committee meeting in Jacksonville, Florida, and as usual I spent most of my time in the Library and Library Evolution Working Groups. You can read about some of the other groups’ work in Jason’s Core report and Torvald’s Parallelism & Concurrency report.

As Jason wrote, several of the Technical Specifications published in the last few years were proposed for inclusion into the next revision of the C++ standard (C++17) and most of them added new features to the Standard Library. That meant that the Library Working Group spent much of the week doing careful review of those large documents, to ensure that what was added to the standard was correctly specified and that it was coherent with the rest of the library. This blog summarizes some of the significant changes from this meeting.

Continue reading “Red Hat at the ISO C++ Standards Meeting (March 2016): Library”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

What is new in OpenMP 4.5

A new version of the OpenMP standard, 4.5, has been released in November 2015 and brings several new constructs to the users. OpenMP is an API consisting of compiler directives and library routines for high level parallelism in C, C++ and Fortran programs. The upcoming version of GCC adds support for this newest version of the standard.

This post highlights some of the latest features, changes, and “gotcha’s” to look out for.

Continue reading “What is new in OpenMP 4.5”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

 

Testing GCC in the wild

Currently, the GCC testsuite contains more than fifty thousand tests which make up to two million lines of code. Since we, the GCC developers, try hard to avoid regressions in the compiler, almost every change to the compiler or to a related library requires a new test or a set of tests to be added. Hence the internal testsuite keeps growing at a rapid pace. It goes without saying that a new change should not break any existing test.

Despite all this effort, new bugs still creep in. Because it is best to discover as many bugs as possible before a particular version of the compiler is released, many distribution maintainers try to rebuild all the packages in the distro with a still unreleased compiler. They file bug reports if they find any bugs to the upstream Bugzilla so that the compiler is up to snuff when it is released. This rebuild typically happens once a year in regression fixes-only stage of the development, i.e. a stage when no new features are being introduced and the development revolves around fixing bugs.

While a new version of GCC is usually released in April, the Fedora project performs a mass rebuild of all the Fedora packages in January or February. Due to limited resources, this mass rebuild is only done on x86_64 architecture.
Since the point is to test GCC, this is a mass rebuild of so-called first order.

We are looking for several classes of bugs here. These include:

Continue reading “Testing GCC in the wild”


Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!