GCC Plugins under my xmas tree?

Over at LWN there is an article on GCC plugins. It touches onto how it would be useful to implement static analysis tools as GCC plugins.

It does not mention that certain optimizations are not feasible without interfacing with the compiler and that there could be a very significant decrease in errors if we the compiler were pluggable with API-specific checks. Wouldn’t it be nice if less developer time had to be spent hunting for common bugs and more implementing awesome new features?

Typically safety is accomplished by executing code in a Virtual Machine that does extra runtime checks with Just In Time compilation to make up for performance losses. This approach has many known performance and footprint disadvantages. It is used by languages like Java and Scheme.

Applications in these languages are slow and/or ship with a JIT compiler to optimize them during their runtime. C++ is compiled ahead of run time and has a reputation for running faster than these dynamic languages. However it also makes it a lot easier to make mistakes such as leak memory and buffer overflows. One can use the C++ OO system to perform extra-runtime checks to avoid some of these issues but that tends to cancel out any performance advantages of writing code in C++.

Another approach is to enforce various safety-related properties through the compiler. Awesome existing languages such as OCaml come with a strict type system that ensures that once code compiles it will run fast and have a lower bug percentages than comparable code in other languages. EcmaScript4 will feature a rocking type system similar to OCaml.

C++ does not have such an awesome typesystem. However, there are many C++ errors that occur frequently and should be detected by the compiler, however long as there is no way to specify Mozilla-specific type system restrictions the compiler has no way of getting that information. Such plugins provide a certain piece of mind that once code complies with whatever rules we set for it, it is more likely to run correctly. Furthermore, some optimizations that we have in mind for Mozilla 2 (such as incremental garbage collection) will be much easier to work with if the compiler flags memory misuse at compile time.

Currently we can use dehydra to scan the codebase, but it would be much more efficient to be able to plug such verification abilities into every developer’s GCC. I sincerely hope that whoever is in charge of the plugin decision at GCC will realize the massive advantage this would give to GCC over other compilers.

ps. Another use for plugins is to enable more aggressive optimizations. Small changes in the sourcecode can affect how conservative the generated code this. A clever plugin could warn whenever gcc cancels an optimization due to misbehaving source.

6 comments

  1. You obviously don’t subscribe to LWN, you cheap bastard!

  2. Do these plugins have to be present at compile time (of GCC). If GCC has a system for dynamically loading them we could go the route of making these ourselves, right?

  3. John, actually my lwn subscription was the first thing I bought when I got my first real job.

    Ben, that’s all we want. Someone even suggested going the LD_PRELOAD way, but gcc isn’t linked with rdynamic, so it’s not possible.

  4. I presume there’s nothing of the sort for MSVC?

  5. Microsoft seems to focus most of their static analysis work on C#. Recently microsoft research started a harder push into C/C++ analysis, but I don’t think anything customizable has shipped yet.

    I did find PreFast, but it only does some pre-canned tricks.

  6. Is there a doc of the incremental garbage collection work that’ll be done for moz2 ?

    Recently I got concerned GC won’t play well together with memory swapping under available memory condition. Can incremental garbage collection be smart enough to guess a memory zone hasn’t been touched in a while, and avoid causing the OS to swap it back in memory only for GC scanning ?