Figure 9.9: DevRocket simulation.
The desktop initially has three windows open: DevRocket itself, an Xterm serial console connected to the simulated target board, and the target simulation. The first thing to notice is a new top-level menu item, MontaVista, the contents of which are shown in Figure 9.10.
Figure 9.10: MontaVista menu.
This menu provides access to most of MontaVista’s extensions. Note the range of new objects that can be created. The memory analysis and profiling tools can be started from here. There are facilities for license and edition management that bring up corresponding preferences pages. The RSS Feeds item brings up a Feeds view where you can see RSS feeds from your favorite news sites.
This version includes the Platform Development features so the menu includes a number of kernel development items. The Kernel Project lets you configure and build a Linux kernel and subsequently debug it using KGDB.
KFT stands for Kernel Function Trace, which is effectively a profiling tool for the kernel. It adds instrumentation callouts to every kernel function entry and exit to generate a trace log of function execution with timing details. This adds considerable overhead to the kernel, so it’s not particularly good for revealing precise timing problems such as race conditions, but it is useful for identifying bottlenecks such as functions with long execution times and those that are called frequently.
9.3.3 Platform Image Builder (PIB)
One of the tasks required for an embedded Linux device is to create a file system. What goes in it, what can you leave out? Creating a file system by hand can be a tedious, iterative process as you work through the various feature dependencies.
Platform Image Builder is a combination of a project creation wizard and a perspective to help guide you through the process of building a file system from RPM packages.
You can also add your own applications and libraries from projects in your workspace by importing the files into the Image Builder project.
The Platform Image perspective, Figure 9.11, includes a Platform Image Builder editor that lists the packages available for inclusion in the file system. Here you select the pre-defined packages you need and the wizard works out the dependencies from the RPM database as you select them. The editor includes filtering and grouping options to make it easier to navigate through the package list.
Figure 9.11: Platform Image Builder perspective.
When you highlight a package in the Packages tab, details about the package such as version, release information, and dependencies show up in the Properties view. This information comes directly from the RPM database. Other tabs in the editor include Files, which details the structure of the file system, and Images, which lets you specify one or more mount points on the target. Each mount point gets its own image. The Options tab lists optional features of the build. The output of the Platform Image Builder editor is a file called default.pib.
There’s another file in the project called default.exp, which stands for “exports.” The name strikes me as a little odd because what it really does is identify directories, files, and symbolic links to be added to the file system. This file is managed by an Exports editor.
The Outline view shows the packages that have been selected as well as the required supporting packages.
The final output of an Image Builder project is a binary image of the file system called default.<file_system_type> where <file_system_type> represents the type of file system you’re building, such as ext2 or ext3, jffs2, and so on. The file system type is specified in the Images tab of the Platform Image Builder editor.
9.3.4 Memory Analysis Tools
DevRocket includes two memory analysis tools: a memory leak detector and a usage analyzer. The leak detector is based on mpatrol, an open source library that wraps malloc() and free() functions, and the C++ new() operator, with instrumentation that logs each call to these functions. mpatrol is a dynamically-linked shared library, so there’s no change to the application.
DevRocket wraps the text-based mpatrol library and utilities with a graphical Eclipse front end to make it easier to work with. To run a program with memory leak detection, you create a Memory Leak Detection run configuration from the MontaVista menu. This is much like any other run or debug launch configuration, with the addition of a tab for configuring mpatrol (Figure 9.12). The defaults seem to be just fine.
Figure 9.12: Memory leak detection launch configuration.
When you click Run, DevRocket invokes mpatrol to run the program and then brings up the Memory Leak Detection perspective, with views that display the contents of the mpatrol logs. Figure 9.13 shows a Call Graph in the Memory Leak Detection view.
Figure 9.13: Memory Leak Detection view.
The memory analysis tool is intended to help you find memory usage problems quickly and accurately by providing a graphical depiction of memory usage across the entire system. Memory analysis starts with a high-level view showing relative memory usage for the whole system. From there you can drill down into kernel and applicationspecific memory usage. Drilling down even further, you can view a memory map for each application.
From the menu bar, select MontaVista→Memory Usage Analyzer. This brings up the Memory Usage Analyzer view, shown in Figure 9.14. From here you can click on Applications or Kernel to get more detail. Figure 9.15 shows memory usage by user space applications. The kernel usage graph shows memory allocated by vmalloc(), allocated as slabs, and memory used by page tables.
Figure 9.14: Memory Usage Analyzer view, system level.
Figure 9.15: Memory Usage Analyzer view, applications.
The information for the Memory Usage Analyzer comes from /proc files. There are a number of virtual files in the /proc directory and in the subdirectories for each process that provide information on memory usage. The Memory Usage Analyzer simply collates this information in a convenient, easy-to-understand format.
9.4 Wind River — Workbench
Wind River’s entry in the Eclipse IDE sweepstakes is called, simply, Workbench. The current version is 3.0, based on Eclipse version 3.3.1. Workbench supports both Linux and Wind River’s proprietary operating system, VxWorks. In addition to the standard GNU compiler, Wind River also supplies its own compiler with support for multiple target architectures. In addition to supporting both VxWorks and Linux code development, the Wind River compiler also supports stand-alone applications. It also has a number of simulators so you don’t need a target for debugging.
9.4.1 Getting the Evaluation
I downloaded an evaluation version that supports on-chip debugging. Workbench for On-Chip Debugging (OCD) uses in-circuit emulation (ICE) to target tasks such as board bring-up and flash programming, where a software debugger such as GDB may not yet be operational. While the full Workbench OCD product supports debugging Linux and VxWorks projects, the evaluation version is limited to stand-alone projects.