News Archive (1999-2012) | 2013-current at LinuxGizmos | IoT and Embedded News Feed |    About   

Podcast profiles embedded Linux code analysis tools

Sep 14, 2007 — by LinuxDevices Staff — from the LinuxDevices Archive — views

TimeSys has published another episode in its series of free, half-hour podcasts about embedded Linux development. In the new edition, hosts Gene Sally and Maciej Halasz discuss half a dozen free code analysis tools, including both dynamic and static tools.

Dynamic tools examine code while it's running. The application under test is typically “instrumented” at link time, when special functions are substituted for standard C library calls. For instance, special versions of malloc and free in mpatrol can find memory leaks by discovering memory that is allocated but never freed, the co-hosts note.

They mainly discuss valgrind (pronounced “val grinned”), mpatrol, and electric fence, leaving out discussion of commercial alternatives. They seem to prefer valgrind, in part because it supports extension by user plugins. However, they note that mpatrol has the widest target support.

The penalty of dynamic testing is performance, however; Sally estimates that data generation overhead and processing overhead lead to performance as much as 100 percent slower. He said, “Some instrumentation is okay to leave in applications, but not code analysis instrumentation. It's better to leave home without it.”

Next the team takes a look at static code analysis tools, focusing mainly on lint's GNU knock-off (Gnock-off?), “splint.”

Not unlike a spell-checker or grammar parser, static code analysis tools work by searching source code for semantic errors — improper memory handling, scope errors, stack-pointer errors, and array out-of-bounds issues are a few mentioned by the podcasters. Unlike a simple spell-checker, static code analysis tools generally create a “parse tree” first — a process that can take as long or longer than actually compiling code.

The podcasters sensibly conclude that a mix of static and dynamic tools gives testing teams the best chance of doing their work effectively. Each type can provide code analysis that the other kind can't do.

Then, perhaps realizing they have a few more minutes of airtime remaining, the pair broach the topic of gprof, and the discussion returns once more to dynamic profiling. They note that gcc is rarely built without gprof, and thus adding the -g flag will produce a binary that generates voluminous data about “what line runs when, and how long it took,” Sally said. Noting that TimeSys's Eclipse-based IDE integrates gprof, the pair opine that gprof is underutilized, in part due to ignorance of its existence, and in part due to ignorance of how to evaluate its output. “There's fantastic documentation at,” Sally said, “But you have to read the documentation.”

After a brief discussion of uno, a kind of lightweight version of lint that ferrets out only uninitialized data, nil-pointer dereferencing, and out-of-bound array indexing, the pair hint that sparse could be the focus of next week's podcast. Sparse in a tool that's embedded in the kernel itself, and aims to offer static analysis of actual kernel source code.

As per usual, the latest podcast edition can be found here.

Henry Kingman

This article was originally published on and has been donated to the open source community by QuinStreet Inc. Please visit for up-to-date news and articles about Linux and open source.

Comments are closed.