Exercises 3: Compilation Tools: Editor, Compiler, Linker, Debugger, Make

Goal:

This exercise session should get you acquainted with the tools we will use for editing, compiling, running and debugging programs. The tools are:

• the emacs editor

• the gnu C compiler (gcc), assembler and linker

• for the C++ experts: the g++ gnu C++ compiler, assembler and linker chain

• make, the tool to automatically build executables from source files

• the gnu debugger (gdb)

Exercise 1: emacs

Start the emacs editor. Read through the on-line tutorial and try everything. You may edit the yesterday.txt file from last week’s exercise.

• Scroll up and down the text

• do a copy / past

• search for the string yesterday in the text

• replace all yesterdays by tomorrow

• split the screen into 2 editing windows and write some text into the second window.

• Save the text in the second window to a file named myfile.txt

• Restrict the editor to 1 window again

• switch from one editing buffer (yesterday.txt)

• revert to the original yesterday.txt

• keep on playing trying the functionalities in the pull-down menus

• In the options menu switch on “Highlight matching parenthesis” and take the cursor to one of the curly brackets. What do you observe?

• Type the following program:

• When typing, deliberately miss out the curly bracket after if (a<b) and continue typing. How does your indentation look like if compared to the one on the screen shot?

• Insert the curly bracket. Put the cursor at the beginning of the file and type the tab key at each line. Put a few blanks before the else and the re-do the tab exercise. What do you observe?

Exercise 2: Makefiles

Up to now we always compiled our program using the gcc compiler command directly. Already with the calculator you have seen that this becomes clumsy because we have to call the compiler 6 times (5 time to compile into object files and once for linking).

We have seen the make command in the lectures which will reduce these 6 commands into a single one (namely “make”), which in addition will only do the compile and link actions that are really needed.

For all last week’s exercises create Makefiles which have at least these targets:

• the final executable

• clean, which will remove all files that are not needed to build the program (emacs backup files ending in ~, all .o object files, the executable.

• run, such that make run will run the program. If we have these we can edit, compile and link, run the program all from within emacs

• include -Wall in CFLAGS to the compiler. This will print all warnings which may otherwise be suppressed.

Each of the targets can be run individually. Create a target to compile into an assembly language file:

hello.s: hello.c

$(CC) $(CFLAGS) -S $?

What does this do? Have a look at the created file either with more or with emacs.

Once you have created a Makefile you can compile your program from within emacs. Produce a deliberate syntax error and see how emacs reacts when you compile. Click with the middle mouse button on the error message. What happens?

Go through the Makefile examples attached as archive file at the end of this page (you should know by now how to unpack it) and make sure you understand what they are doing. Use these as templates for your own Makefiles.

Create Makefiles for the code examples on C programming we had last week.

Exercise 3: gdb

In last week's codeExamples there is a folder called wrong. It contains an attempt to calculate the Fibonacci series. First have a look at the Makefile. CFLAGS contains the option -g to keep the symbol table. Compile the program and execute it. You will see that something goes wrong.

Start gdb on the program. Insert a break point at main and step through the program printing the contents of the variables. Try to figure out like this where things start to go wrong.

Once you found the bug, correct it (but keep the wrong program as well) and re-run the program in gdb verifying that things are ok now.

Try the trick with conditional compilation using #define DEBUG 1. Where would you place the print statements? Once the bug is corrected, comment the #define statement, recompile and make sure the debugging prints have gone.

In a library you may want to write a function setDebug(bool) changing the state of the debug variable. Try to implement this as well.

Homework:

Write a traffic light simulator: Imagine a road crossing where you have traffic lights on both roads. When the traffic light is green on one road it must be red on the other. The traffic lights are in this state for some time to make a good number of cars pass the crossing. Then the green light turns to yellow while the light on the other road is still red. This is a short phase just allowing the cars, which are already on the crossing to clear it. Then we keep both lights on red for a short period as a safety phase, before switching the other traffic light to green, again for a longer period.

There are therefore the following phases:

Traffic Light 1	Traffic Light 2	Period
green	red	long
yellow	red	short
red	red	short
red	green	long
red	yellow	short
red	red	short

In the end we will display the result on red, yellow and green LEDs on the Raspberry Pi. For the moment however, just print the state of each of the 6 lamps (on or off) on the screen.

-- Uli Raich - 2017-09-11

Comments