You are all invited to grab the slides or watch the video (in Hebrew only right now, sorry) at the lecture page.

Wonderful as these tools are, however, they are not omnipotent and cannot guess what’s on our minds. Would this function we just wrote get called very often or no? is that if statement where we are going to take the if branch more often then the else one, or is it the other way around? the compiler simply can’t tell, without our help that is.

Supplying the compiler some hints when writing code, can be very beneficial in enabling the compiler to properly optimise the code it produced for best performance, how ever that is defined.

In this post we shall describe several hints that we can provide to GCC and G++ compiler to help them understand our program run time behaviour better and ultimately produce better code.

There are two types of constructs to provide hints to GCC and G++ about the run time attributes of the code you write for the purpose of optimisation: function attributes and built-ins.

Function Attributes

Function attributes are modifiers you add to function  definition that supply the compiler with additional information about that function run time behaviour. The canonical form of an attribute in GCC and G++ is:

__attribute__((name))

Where “name” is one of the reserved attributes names. Many such attributes exists and you are encouraged to read the GCC documentation about them.

For example, this is how a function defined with the “pure” attribute will look like (more on the pure attribute itself later):

int my_func(int i)  __attribute__((pure));

One very common shorthand form  that is often used in large project (for example, the Linux kernel), is to use a pre-processor define to make the attribute use less verbose, like so:

#define __pure __attribute__((pure))
 
int  my_func(int i) __pure;

Or, as I prefer:

int   __pure my_func(int i);

I shall use this shorthand form hence forth.

Now that we have established what are function attributes and how to use them, let us go over a list of such attributes which can be used to provide hints to the compiler and allow it to better optimise our code:

The pure function attribute

Many functions that we write are pure functions. A pure function is a function whose only effect is it’s return value and the return value, in turn, depends solely on the parameters to the function and/or gloval variables, such as that if we call the function with the same parameters and the same values in global variables we are guaranteed to get the same return value.

As an example, the functions strlen(3) and memcmp(3) are good examples for pure functions; their return value is solely dependant on their input parameters. On the other hand, the feof(3) function is a not a pure function, because, in a multi-threaded application, some other thread might have changed the state of the file the file descriptor is referencing between two calls of the function.

Compilers can make use of the knowledge that a certain function is a pure function by performing such optimisations such as common sub-expression elimination in the same way that this is done with arithmetic operators such as “+” or “*”.

Using the pure attribute, we can tell GCC and G++ that a certain function is a pure function and therefore might be a good candidate to optimisation. For example:

size_t __pure strlen(const char *) ;

Note that the pure attribute is not implemented in GCC versions earlier than 2.96.

The hot and cold function attributes

An additional pair of function attributes which you can use to help GCC and G++ emit better code are the hot and code function attributes:

__attribute__((hot))
__attribute__((cold))

As their name suggests, these function attributes are used to hint the compiler that the corresponding functions are called often in your code (hot) or seldom called (cold).

The compiler can then order the code in branches, such as if statements, to favour branches that call these hot functions and disfavour functions cold functions, under the assumption that it is more likely that that the branch that will be taken will call a hot function and less likely to call a cold one.

In addition, the compiler can choose to group together functions marked as hot in a special section in the generated binary, on the premise that since data and instruction caches work based on locality, or the relative distance of related code and data, putting all the often called function together will result in better caching of their code for the entire application.

Good candidates for the hot attribute are core functions which are called very often in your code base. Good candidates for the cold attribute are internal  error handling functions which are called only in case of errors.

Here is a usage example:

int __hot call_me_often(void);
int __cold handle_error(void);

The hot and cold attributes are available GCC version from 4.3 and onwards.

Built-ins

Another form of hints that can be a programmer may provide to the compiler about the code run time behaviour for the purpose of optimisation, are calling a built-in compiler function.

Data pre-fetching and cache pre-population

As you are most probably aware, fetching information from RAM is a costly business in the terms of a computer program. This is why an elaborate system of internals on CPU and off CPU caches are used to store recently accessed data and instructions in the hope that these will be needed again soon and thus the cost of fetching them from RAM can be saved.

Most chip architectures and compilers do a pretty decent job working together to automatically populated the various caches with the right data and instructions in order to achieve better performance. Sometime however, a programmer can provide a hint to the compiler about what data might be needed in advance of time, thus allowing the compiler to emit instruction that will fetch the data from RAM to the cache while the CPU is busy doing other processing, thus making sure the data is available in the cache when the CPU gets around to needing it.

The way to do this with GCC and G++ is to use the built-in pre-fetch function:

void __builtin_prefetch( const void *addr, int rw, \
  int locality );

The built-in pre-fetch function will cause the compiler to emit instructions that will pre-populate the cache with the data at address addr. Note that it is allowed to provide an illegal address to pre-fetch.

The optional rw parameter indicated whether the requested access is for read purposes or write (1 denotes read/write access while 0 denotes read only), whereas the optional locality parameter  describes the temporal locality of the data. That is, the degree to which it is likely the same data will be used again soon and therefore whether or not to keep the data in the cache after it is used (0 means “do not keep at all” and 3 denotes “keep as long as possible”).

As an usage example, consider the common operation of traversing a linked list. Typically, we iterate over the list, processing each item in turn and then progressing to the next list item:

while (!item) {
  item->field++;
  // more processing...
  item++
}

Using the built-in pre-fetch function, we can write the same code like this:

while (!item) {
  // Not NULL check since invalid addr OK
  __builtin_prefetch(item->next, 1, 1) ;
  item->field++;
  // more processing...
  item++
}

Adding the pre-fetch call will allow the compiler to issue instructions that will get the CPU to start the transaction that will get the data for the next item fetched from the main RAM to the cache while processing the current field which is in the cache. With any luck, by the time the CPU finished processing the current item, the next item will have already been pre-fetched and populated the cache, just in time for it being processed.

Proper use of pre-fetching and cache pre-populating can sometime have a dramatic effect on the performance of some kinds of computer programs.

Branch annotation

Branches in program code path, such as those that happen due to an if statement, are challenging for modern CPUs. As most modern day CPUs makes use of multiple pipelines of instructions that execute in parallel, a branch in a program is problematic since the CPU does not know for sure in advance which branch will be taken until it has executed the entire instructions that lead up to the branch, thus stalling the pipeline.

The solution taken by CPU makers for this problem is the introduction of branch prediction logic into the CPU which tries to estimate which branch will be taken and try to advance with the pipeline based on that estimation. If the assumption is later proved to be wring, the CPU aborts the pipeline and starts over; a costly business.

As you probably have guessed by now though, we can use the knowledge we have as programmers about the program flow and hint the compiler about the chances that a certain branch, or if statement, will be taken or not. The compiler in turn, will use this information to bias the CPU to prefer to proceed with the most probable branch, the one least likely to cause a hazard and an abort of the pipeline.

Other benefits are that the compiler can re-order the binary code such that the code most likely to execute in a branch will be closest to the branch instruction itself, thus preserving code locality and therefore assisting caching.

Providing the GCC and G++ compilers with the probable outcome of a branch, we use the built-in expect function:

__builtin_expect(!!(x), e)

The function is used by applying it to a branch predicate, such as in the following example:

if(__builtin_expect(!!(condition), 1)) { ... }

The x parameter to the built-in expect function is the predicate we test in the if statement and the e parameter is the most likely outcome of evaluating the predicate as a Boolean value: true or false.

Often, the built-in expect function is wrapped for convenience using two macros. Such is the case in the Linux kernel source, for example -

#define likely(x)	__builtin_expect(!!(x), 1)
#define unlikely(x)	__builtin_expect(!!(x), 0)

Using these macros, the usage becomes the following, which is much more readable:

if(likely(condition)) {...}

It should be noted that GCC also provide a run time parameter -fprofile-arcs, which can profile the code for the actual statistics for each branch and the use of it should be prefered above guessing.

Conclusion

We have detailed above several note worthy way to providing hints to GCC and G++ compilers about your code behaviour in run time, hints that allow the compiler to better optimise your code and therefore achieve superior performance. Making a habit of using these hints as part of your normal code writing routine can easily provide substantial returns on a long enough scale.

Care should be taken however, to not get these hints wrong, as there is nothing worse then providing your compiler with the wring hint and thus “pessimising” your code instead of optimising it.

fork() and related call vfork(), which create a new process, complete with it’s own process id, private address space and a private copy  set file descriptors, file system attributes (such as working directory) and signal handlers, all distinctly separate from those of the parent that called the fork() function.

And pthread_create(), which creates a new thread inside the existing process, which shares the same process id, address space, file descriptors, file system attributes and signal handlers with the caller.

Looking at these two options it would seem that were are faced with a “share all or share nothing” attitude - either we go the new process route and get a private copy of everything  (actually Linux employs copy on write semantics to make more efficient use of memory), or we can go the new thread route share all resources and for the most, these options are sufficient for most needs.

Sometimes, however, a less black and white approach is called for - such as a case where we would like to create a new context of execution sharing the file descriptors and file system attributes of the creator, but not it’s address space (or maybe juts a portion of it) and process id, for example.

For these cases exactly Linux offers clone(2). Clone is a library function implemented inside the C library, Glibc, which layered on top of the underlying sys_clone system call.

Clone is similar to fork(2) and pthread_create(3) in that it creates a new execution context which are scheduled independently from the creator.

Unlike fork and pthread_create, however, clone provides a fine grained level of control of the properties of this new context:

• What it will and what it will not share with its creator.
• Which parent process will it belong to.
• Which signal, if any, will be delivered to its parent when it terminates.
• Where is the location of the new task call stack.

As an example, here a code snippet that creates a new task (for lack of a better word), which implements our previous example - a new process which has its own process ID, a private address space (with a copy on write semantic of the creator address space) and a separate set of signal handlers, but shares with its creating process the table of file descriptors, file system attributes:

#include <ched.h>
 
#define STACK_SIZE 4096
 
void * stack = mmap(NULL, STACK_SIZE , \
   PROT_READ | PROT_WRITE, MAP_PRIVATE | \
   MAP_ANON | MAP_GROWSDOWN, -1, 0);
 
/* check for alloc errors... */
 
clone(test, stack, CLONE_FS | CLONE_FILES \
    | SIGCHLD| CLONE_PARENT, NULL);
/* check for clone errors... */
 
munmap(stack, STACK_SIZE);

As you can see in the example above, we first allocate a stack for the new task using an anonymous private memory mapping and instruct the kernel to grow the mapping downwards as need be (this is actually not true on all architectures).

Them, we use the clone library call to create the new task, sharing the file descriptor table and file system attributes, but not the address space with the creator.

We also ask that the new task will inherit the same parent as the creator and that a SIGCHLD signal will be sent to the parent of the new task, as normally would be the case.

As you can see, the clone library call and the sys_clone are a powerful tool that can be used to create unique execution contexts beyond the standard thread or process variety. Many more options are detailed in the clone(2) man page.

Gilad

Thanks you Zaar and we look forward to hosting you again in Herzelinux club meeting as well as here.

Tuxology Team.

To the article…

While one can develop and test much of our code on a PC running Linux, such a PC is a very different environment from the target board. More often then not, the target board is not even of the same architecture as the PC. A solution to this problem can be obtained by using an emulator - a software tool that executes software code of our target platform in a virtual machine that is running on our development host, and running our system software in it.

The following article describes how to build an embedded Linux system running inside an emulator which can be used to develop, test and debug target code even without access to target hardware.

The components

To build our emulator we will need the following components:

• Hardware emulator (we’ll use Qemu)
• Minimal Linux root file system containing a C library and Busybox
• The Linux kernel

Installing Qemu

As first step, we will download and install the Qemu emulator. Qemu is an Open Source machine emulator supporting seven target architectures, including x86, MIPS, Arm and PowerPC, creating by Fabrice Ballard.

Depending on the Linux distribution you use as a workstation, you might be able to use the native package management system of the distribution to get do that.

For Debian, Ubuntu and derivatives:

$ sudo apt-get install qemu

For Fedore and derivatives (as root):

# yum install qemu

For other distributions lacking a Qemu package or those wishing to obtain the very latest package. Note that the “i386″ label refers to the host running the emulator and not the target platform:

$ wget http://bellard.org/qemu/qemu-0.9.1-i386.tar.gz
$ cd /
$ sudo tar zxvf qemu-0.9.1-i386.tar.gz

Or, as root:

# tar zxvf qemu-0.9.1-i386.tar.gz

Alternatively, you can download the sources and build the emulator from scratch. This has the added advantage that you can later adapt the emulator to more accurately reflect your actual hardware:

$ wget http://bellard.org/qemu/qemu-0.9.1.tar.gz
$ tar zxvf qemu-0.9.1.tar.gz
$ cd qemu-0.9.1/
$ ./configure
$ make
$ sudo make install

Or, as root:

# make install

Kernel and file system images

The Qemu emulator we have just installed provides a virtual machine mimicking our target hardware. To actually get Linux running on this virtual machine however, we will need to download an image of the Linux kernel and a suitable root file system image for our target architecture.

Luckily, the Qemu project provides several test images for several architectures supported by Qemu that can be used to get a fast start with Qemu as an embedded Linux system emulator.

Go to the Qemu project download page and choose one of the Qemu test disk images suitable for your embedded platform and download it to your Linux host (in this example we use arm):

$ wget http://bellard.org/qemu/arm-test-0.2.tar.gz

Now extract the image:

$ tar zxvf arm-test-0.2.tar.gz
$ cd arm-test

Booting Linux on the emulator

Start up Qemu with the following command line, adjusting the architecture name, kernel file name and root file system image name according to your specific architecture (again, we use arm in this example):

$ qemu-system-arm -kernel zImage.integrator \
   -initrd arm_root.img -tftp / -redir tcp:9999::9999

The above command line starts Qemu in system emulation mode, booting into the kernel image zImage.integrator while loading into the virtual machine RAM the arm_root.img file system and instructing Qemu to make your entire host root file system available for access via TFTP from the emulated machine (more on this ahead).

You should now be seeing a window similar to the following in which the emulated LCD display of the board is shown:

Qemu screenshot

You can log-in with the user “root”. No password is required.

Transferring files to and from the host

The emulator and file system are set up to automatically configure a virtual Ethernet interface in the virtual machine with an internal IP. Through that virtual network interface, the emulator is set up to enable transferring of files to and from the host machine file system using the TFTP protocol.

For example, the following command will copy the file “/home/gby/hello_emu” from the host file system to the current directory inside the emulator:

$ tftp -g -r /home/gby/hello_emu -l hello_emu 10.0.2.2

The following command will copy the file “/root/test.log” from the emulator to the host file system directory “/home/gby/”:

$ tftp -p -l/root/test.log -r /home/gby/test.log 10.0.2.2

In addition, you can use the “wget” comment to transfer files using the FTP and HTTP protocol to the emulator from any compatible server accessible in the network:

$ wget http://codefidence.com/some/file

Qemu supports numerous other way to interact with the host and it’s environment, including bridged virtual network interfaces (as opposed to the default NAT used in the example above) which enables both using NFS to communicate with the host as well as remote debugging from the host, VLAN support, exposing the host file system as a FAT file system, mounting disk, flash or CDROM images from the host file system and even using USB devices connected to the host. For more information on these advanced options, please refer to the Qemu user manual.

Debugging user applications

Using the GNU debugger GDBserver agent, we can debug applications running inside the emulator using the GDB debugger on the host. To do this, first copy (using one of the methods outlined above) the “gdbserver” executable to the emulator. Note that you will need a “gdbserver” executable which was built to run on the target architecture (such as Arm, in the example above) and not on the host!

Also note that since the test images do not contain debugging symbols for the system libraries, you will only be able to debug statically compiled application using them. This limitation can be removed by building your own kernel and file system image (see below for more information on this topic).

$ tftp -g -r /home/gby/src/gdb/gdb/gdbserver/gdberver \
   -l gdbserver 10.0.2.2

Next, assign the gdbserver binary execute permissions:

$ chmod u+x gdbserver

Now, run the gdbserver agent, instructing it to use port 9999 (which have redirected to the emulator using the qemu command line) to listen for connections from the debugger:

$ gdbserver 0.0.0.0:9999 /bin/myprog

Or, if you wish to attach to an already running program, use:

$ gdbserver 0.0.0.0:9999 --attach 1234

Finally, run the GDB debugger on your host and instruct it to connect to the host local port 9999 (which the emulator is redirected to the virtual machine):

$ arm-linux-gdb target/bin/myprog
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) set solib-absulote-prefix /dev/null
(gdb) set solib-search-path target/lib/
(gdb) target remote 127.0.0.1:9999

Debugging the kernel

Using the Qemu emulator to debug kernel code is quite straight forward as Qemu incorporates a minimal GDB agent as part of the emulator itself. To debug the Linux kernel running inside the emulator, add the “-s” parameter to the command line used to start Qemu:

$ qemu-system-arm -kernel zImage.integrator \
    -initrd arm_root.img -tftp / -redir tcp:9999::9999 -s

Now when the emulator will start, it will wait for a debugger connection on the default port “1234″ (or a different port specific with the “-p” option) , before proceeding with the boot. Once the emulator has started, you can debug the Linux kernel running inside using GDB on the host:

$ arm-linux-gdb linux/vmlinux
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
...
(gdb) target remote 127.0.0.1:1234

You can use GDB as you normally would. For example, type “cont” to launch the kernel:

(gdb) cont

Building your own kernel and file system images

So far we have seen how to use the Qemu emulator with the test kernel and file system images that are available on the Qemu site. To make full use of the emulator, we can create our own custom kernel and file system images that will better reflect the real target we are trying to develop for.

First, query Qemu regarding which boards it can emulate for you chosen architecture. Replace “arm” in the example above with one of: mips, x86_64, ppc or sparc. For i386, simply use “qemu” as the command:

$ qemu-system-arm -M \?

Choose the board that most closely resembles your real target environment. Note that you can add support to Qemu of your specific true board. This requires some programming though and we shall not cover it in this tutorial.

The creation of kernel and file system for our emulated target is no different then doing the same task for a real hardware and in fact. Many tools are freely available to accomplish this task. In this example we shall use the Buildroot framework. Buildroot is a set of make files and patches that makes it easy generate a cross-compilation tool chain and root file system for your target Linux system using the uClibc C library:

First, we shall download the latest Buildroot release from the project web site and extract it:

$ wget http://buildroot.uclibc.org/downloads/snapshots/buildroot-snapshot.tar.bz2
$ tar jxvf buildroot-snapshot.tar.bz2
$ cd buildroot/

Next, let’s configure Buildroot for our chosen target board:

$ make menuconfig

You will be presented with a menu enabling you to pick your architecture, sub-architecture, specific board to build for, GCC and uClibc versions and related details. For each entry of the configuration tool, you can find associated help that describes the purpose of the entry.

At minimum, the following configuration options needs to be set:

• Target Architecture option - choose your target architecture (e.g. arm.)
• Target Architecture Variant option - chose a specific model of the architecture (e.g. arm926t.)
• Target options menu - if the target board you wish to emulate (that is supported by Qemu) is listed, turn on support for that board (e.g. enable the “ARM Ltd. Device Support” menu and inside it choose the “Integrator arm926″ option).
• Toolchain menu - turn on “Build gdb server for the Target” option and if you would like to test C++ programs on the emulator, also the “C++ cross-compiler support” option.
• Target filesystem options menu - enable the “cpio the root filesystem” option and choose the “gzip” compression method. You may also request the file system image to be copied to a specified directory once it is generated here.

• Kernel menu - choose the “linux (Advanced configuration)” option and pick one of the offered Linux kernel versions of the list offered. Also, select the “zImage” binary format. Here you can also specify a directory to copy the generated kernel to.

  In addition, you will need to supply a proper Linux kernel configuration file. Note that you extract the kernel configuration configuration file used to generate the kernel supplied as part of the test images by issuing the following command when inside the emulator:

  $ zcat /proc/config.gz > linux.config

  Alternatively, Linux provides specific kernel configuration for optimal use with Qemu for some architectures. Run the following command to inspect the default kernel configuration included in a specific Linux kernel version:

  $ make help

When you’ve done configuring Buildroot, exit the configuration utility (making sure to OK saving the changes) and type: “make”. Buildroot will now download all required sources and build your new kernel and file system image for you. You should now be able to run the emulator using the kernel and file system image you have just created. Use the file name and path of the zImage binary as a parameter to Qemu “-kernel” option and the file name and path of the file system image to the Qemu “-initrd” parameter, like so:

$ qemu-system-arm -kernel zImage \
    -initrd rootfs.arm.cpio.gz -tftp / -redir tcp:9999::9999 -s

Conclusion

As we have shown, the Qemu emulator provides a fairly simple way to develop, debug, and test Linux kernels, drivers, and applications for a variety of embedded architectures, even when no actual hardware is available. More information about the software used in this article can be found on the qemu, gdb, and Buildroot websites.

Fixes and conclusion by Henry Kingman from LinuxDevices.com. Thanks Henry!

For those of our reader which were absent, fear not! not only are the slides for the lecture available here, Rami posted an excellent article based on the lecture on LinuxDevices.com.

Thanks you Rami and we look forward to hosting you again in Herzelinux club meeting as well as here.

Tuxology Team.

The released video includes the following:

• Keynote: The Kernel: 10 Years in Review, by Matthew Wilcox (Intel)
• Talk: Tux on the Air: State of Linux Wireless Networking, by John W. Linville (Red Hat)
• Talk: Suspend to RAM in Linux: State of the Union, by Len Brown and Rafael Wysocki (Intel)
• Talk: Real Time vs Real Fast: How To Choose?, by Paul E. McKenney (IBM)
• Tutorial: ftrace: latency tracer, by Steven Rostedt (Red Hat)
• BOF: Embedded Linux, by Tim R. Bird (Sony)
• BOF: Embedded Micro controller Linux, by Michael Durrant (Arcturus Networks)
• Talk: Energy-aware task and interrupt management, by Vaidyanathan Srinivasan (IBM)
• Talk: Application Testing Under Realtime Linux, by Luis Claudio R. Gonçalves (Red Hat)
• Talk: Application Framework for Your Mobile Device, by Shreyas Srinivasan (Geodesic Information Systems)
• Keynote: The Making of OpenMoko Neo, by Werner Almesberger (OpenMoko)
• BOF: U-Boot by Wolfgang Denk (Denx)
• BOF: Linux Compiler, by Rob Landley (Impact Linux)
• Talk: Advanced XIP File System, by Jared Hulbert (Intel)
• Talk: SELinux for Consumer Electronic Devices, by Yuichi Nakamura (Hitachi)
• Talk: Around the Linux File System World in 45 Minutes, by Steve French (IBM)
• BOF: Linux The Easy Way with LTIB, by Stuart Hughes (Freescale)
• Keynote: The Joy of Synchronicity: Coordinating the Releases of Upstream and Distributions, by Mark Shuttleworth
• Talk: Smack in Embedded Computing, by Casey Schauffer
• Talk: Bazillions of Pages: The Future of Memory Management, by Christoph H. Lameter (SGI)
• Tutorial: Writing application fault handlers, by Gilad Ben-Yossef (Codefidence)
• Talk: Linux, Open Source and System Bringup Tools, by Tim Hockin (Google)
• Talk: DCCP Reached Mobiles, by Leandro Melo Sales (Federal University of Campina Grande)
• Talk: Building a robust Linux kernel, by Subrata Modak (IBM)
• CELF BOF presentation: Best of recent CELF Conferences, by Tim Bird (Sony)
• CELF BOF presentation: Developing Embedded Linux with Target Control, by Tim Bird (Sony)
• CELF BOF presentation: Embedded Building Tools - An Audience Survey, by Michael Opdenacker (Free Electrons)
• CELF BOF presentation: GCC Tips and Tricks Highlights, by Gene Sally

The videos and related resources can be downloaded from their conference videos page.

I especially recommend viewing the exceptional “Real Time vs Real Fast: How To Choose?” talk by Paul E. McKenney from IBM and the the “The Making of OpenMoko Neo” keynote, by Werner Almesberger of the OpenMoko.

Much thanks to Michael and Thomas for sharing this with everybody.

Gilad