(r3) Lecture4:DevelopmentTools < Embedded

Tags: view all tags
%SLIDESHOWSTART%
---+ Development Tools: Editor, Compiler, Linker, Debugger, Make
<h2 align="center">Uli Raich</h2> <h2 align="center">First Semester 2017/2018</h2>

---++ 
---+ The development cycle

The first and most important part in the development cycle is that *you think*!

Of course a hello world program you can start implementing immediately.

This however is not the case for real world problems.

Break down the problem into small manageable parts that you can

implement and test individually

Think about how these smaller pieces will be interfaced with each other

to create the full program

Make a design on paper or use one of the software design tools.

---++ 
---+ The editor

There are plenty of editors on Linux:
   * vi: the first and traditional full screen editor<br />this one is for die-hard Unix gurus but on some very small<br />Unix system it is the only editor installed
   * emacs: another traditional Unix editor <br />(and my favorite, probably because I know it best).<br />The advantage of using emacs is that the key sequences used <br />for editing are also understood by bash. This is also the favorite of many programmers. <br />People say it can do everything except making coffee.
---++ 
---+ More Editors
   * gedit: the editor that comes with the Gnome desktop
   * joe, jed, nano, ed …
In addition to these we have editors being part of

Integrated Development Environments (IDEs)

   * eclipse: originally developed for Java but has “perspectives” for other languages like C, C++
   * qtcreator: an IDE tailored to development of window based Qt programs. Mainly C++
   * netbeans: tailored to Java but can also do C/C++
---++ 

---+ Linking several object files

We have seen that functions can be implemented in dedicated files.

In our calculator, each operation can be implemented

in a separate function on a separate file.

We then have to compile 5 C programs to object files and

finally link these into the final executable.

The C library is automatically linked as well but we may also

need to link additional libraries (e.g. libm.so the math library).

---++ 
---+ emacs

emacs is written in lisp. It has so many functionalities

that I have no chance to show all during the lectures.

I will give a little demo but you will not be able to remember

all the key sequences even until this afternoon for the exercises

However, many functions are accessible through pull-down

menus and the key sequences are given

Emacs has an online tutorial, which you should have a look at.

---++ 
---+ emacs example

emacs when editing "hello world"

<img alt="emacs-1.png" height="302" src="%ATTACHURL%/emacs-1.png" title="emacs-1.png" width="427" />

---++ 
---+ A more elaborated emacs session

<img alt="emacs-2.png" height="268" src="%ATTACHURL%/emacs-2.png" title="emacs-2.png" width="477" />

---++ 
---++ 
---+ Demo on emacs
<h1 align="center">!!! Interruption !!!</h1>

You want to know how to really use emacs to its full potential?

Get the manual (some 635 pages!)
---++ 
---+ gcc

gcc is the de facto industry standard C compiler

It exists for many different machines

   * Intel processors
   * ARM MIPS
   * And it comes as native or as cross compiler
gcc is open source and you can have a look how to implement such a compiler,

and you can compile the latest version of it yourself

---++ 
---+ gcc components

gcc has several components:

   * The preprocessor<br />this treats the #define and #include statements to <br />build a complete C source file for the compiler
   * The C compiler proper
   * The assembler
   * The Linker
---++ 
---+ gcc options

gcc has plenty of options which may also depend on the compiler version.

gcc for ARM has different options from gcc for Intel.

Here are just a few of them:

   * -Wall<br />don’t ignore any warnings. You may however also specify which <br />type of warnings you are interested in
   * -g keep symbol table for debugging
   * -E only run the preprocessor
   * -S create assembly code and stop
   * -c compile into object code, don't link
---++ 
---+ gcc input and output

Gcc input can be any of the following:

   * C source code: myCode.c
   * Assembly code: myCode.s
   * Object code: myCode.o
   * Libraries: libmylibrary.a or libmylibrary.so
If you do not specify the name of the output file (-o option) the executable will be called a.out

---++ 
---+ make

We have seen that quite a few gcc commands may be needed

even if we only build a ridiculously small program as our calculator

What about a program with thousands of source files?

We need a tool with which we can describe how to build the program

and which will execute all necessary steps automatically:
<h2 align="center">make     </h2>

---++ 
---+ The Makefile

Traditionally the description is called Makefile

(with capital M) even though any other name will do as well

The Makefile contains

   * Macros (similar to Variables)
   * Dependencies
   * targets
---++ 
---+ An example Makefile

<img alt="helloMakefile.png" height="293" src="%ATTACHURL%/helloMakefile.png" title="helloMakefile.png" width="390" />

---++ 
---+ Targets and dependencies

The target is the thing that is to be done in this step:

hello: hello.c hello.h

In this case hello is the target and it depends on

hello.c and hello.h

Then you have the action needed to create the target

which has a tab character (invisible!) before the text:

Tab  $(CC) $(CFLAGS) -o hello hello.c

This will compile and link output the hello executable

---++ 
---+ A simpler Makefile

Make has predefined rules and it knows hot to produce

a .o file from a .c file

We can therefore restrict out Makefile to this:

<img alt="simpleMakefile.png" height="147" src="%ATTACHURL%/simpleMakefile.png" title="simpleMakefile.png" width="410" />

---++ 
---+ Special macros
   * CC is the C compiler, it defaults to cc
   * CFLAGS are the flags to be passed to the C compiler
   * LDFLAGS are the flags to be passed to the linker
   * LDLIBS are the libraries to be linked into the executable
   * RM translates into rm -f
   * $&lt; is the file that caused the action
   * $* is the prefix shared by target and dependent file
   * $@ is the file to be made
   * $? are the dependent files that have changed
   * $^ are all dependent files
---++ 
---+ more Makefile examples

%.o: %.c:

      $(CC) $(CFLAGS) -c $&lt;

Or

      $(CC) $(CFLAGS) -c $*.c

---++ 
---+ Makefile with several object files to be linked

<img alt="complexMakefile.png" height="341" src="%ATTACHURL%/complexMakefile.png" title="complexMakefile.png" width="727" />

---++ 
---+ Makefile improved

<img alt="improvedMakefile.png" height="450" src="%ATTACHURL%/improvedMakefile.png" title="improvedMakefile.png" width="475" />

---++ 
---+ know more about make?

You want to know more about make?

There are several tutorials on the WEB

There is also the official manual which is a

200 pages book!

---++ 
---+ Running the program

To run the program we have to run ./nameOfBinary

Why do you have ./ before the program name and what does it mean?

Is there a means to run the program without the ./ ?

Beginner programmers often think that the job is done once the

program is compiled and all the syntax errors fixed.

The truth is that then the work has just justed.

Often there are programming errors (bugs) in the logic and

the program mis-behaves.

How do we spot these errors?

---++ 
---+ Printing debug information

Very often programmers put print statements purely for the sake of debugging.

This is annoying when running the final program

where this information should not be needed any more.

One easy way out of the dilemma is given by the C preprocessor:

#define DEBUG 1

#ifdef DEBUG

        p rintf(“printing some variable contents %d\n”,variable);

#endif

Commenting out the #define statement will get rid of all debugging prints.

---++ 
---+ The debugger gdb

Sometimes printing debug information is not enough

and we have to use a debugger.

gdb the GNU debugger is still the standard tool

Compile your program with the -g option to retain the symbol table

Then run the program within the debugger

gdb yourProgram

---++ 
---+ Using gdb
   * break: set a breakpoint to stop running when arriving at this point
   * run: start the program
   * continue: continue running after a breakpoint
   * next: execute the program line next line
   * step: step into the function if the next line is a function call
   * list: print the source code at the current position in the program
   * bt: backtrace, show the program stack
   * print: print a variable
For more information read the manual.

This is rather short (a bit more than 800 pages)

%SLIDESHOWEND%

-- %USERSIG{UliRaich - 2017-09-08}%

---++ Comments

%COMMENT%
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who
png	complexMakefile.png	r1	manage	27.5 K	2017-09-11 - 12:26	UnknownUser
png	emacs-1.png	r1	manage	34.1 K	2017-09-11 - 11:27	UnknownUser
png	emacs-2.png	r1	manage	299.7 K	2017-09-11 - 11:27	UnknownUser
png	helloMakefile.png	r1	manage	16.4 K	2017-09-11 - 11:42	UnknownUser
png	improvedMakefile.png	r1	manage	38.3 K	2017-09-11 - 11:42	UnknownUser
png	simpleMakefile.png	r1	manage	6.6 K	2017-09-11 - 11:48	UnknownUser
Topic revision: r3 - 2017-09-11 - uli