Contents|Previous|Next
Using GNU tools 
The following seven GNUPro Toolkit tools can be run on native and embedded targets.
See the following documentation for more discussion on using the GNU tools. See also Using the tools on native and embedded systems and GNUPro Tools for Embedded Systems.

Invoking the GNU tools

cpp, the GNU preprocessor
cpp merges in the #include files, expands all macros definitions, and processes the #ifdef sections. To see the output of cpp, invoke gcc with the -E option, and the preprocessed file will be printed on stdout.
There are two convenient options to assemble handwritten files that require C-style preprocessing. Both options depend on using the compiler driver program, gcc, instead of calling the assembler directly.
For more information on cpp, see The C Preprocessor in GNUPro Compiler Tools.

gas, the GNU assembler

ld, the GNU linker
ldresolves the code addresses and debug symbols, links the startup code and additional libraries to the binary code, and produces an executable binary image. For more information on ld, see Using ld in GNUPro Utilities.

binutils, the GNU binary utilities

The following are the binary utilities, although they are not included on all hosts: ar, nm, objcopy, objdump, ranlib, size, strings, and strip.
For more information on the GNU binary utilities, see Using binutils in GNUPro Utilities.

The most important of these utilities are objcopy and objdump.

gdb, the debugging tool

To run gdbon an embedded target, use Cygnus Insight, or use a gdb backend with the gdb standard remote protocol or a similar protocol, the following two types of gdb backend being the most common.
For more information on debugging tools, see Debugging with GDB in GNUPro Debugging Tools and Working with Cygnus Insight, the visual debugger.
The following routines are always useful for debugging a project in progress.

Cygnus Insight, a visual debugger

GNUPro Toolkit provides the technology and tools for effective, efficient debugging sessions with the standard command-line based debugger, gdb. Also available is Cygnus Insight, a visual debugger with a graphical user interface supporting a range of host systems and target microprocessors, allowing development with complete access to the program state, including source and assembly level, variables, registers and memory.
Insight adds a series of intuitive views into the debug process, and provides the developer with a wide range of system information.
For more information on developing with Insight, see Working with Cygnus Insight, the visual debugger.

Source-Navigator, a source code comprehension tool

Source Navigator is a source code comprehension tool with which developers can extract information from existing code in C, C++, Java, Tcl, [incr tcl] (the C++ extension for Tcl), FORTRAN, Cobol, and assembly programs, using this information to build project databases. The database represents internal program structures and relationships between program components. Source Navigator then uses this database to query symbols and relationships between components and graphically display them. Initialize the Source-Navigator tool from a commandline interface by invoking the following command:
snavigator
For a demonstration of using Source-Navigator, see Source-Navigator demonstration. For more information on Source Navigator, see the main “User’s Reference Guide” and “Programmer’s Reference Guide” documentation, accessible by clicking on the Help menu’s Contents menu item while working with Source-Navigator.

newlib and libstdc++, the GNU libraries

GNUPro Toolkit has the following libraries: newliband libstdc++.
CygwinTM: a Win32 porting layer for UNIX applications
CygwinTM, a full-featured Win32 porting layer for UNIX applications, is compatible with all Win32 hosts (currently, these are Microsoft’s Windows NT/95/98 systems). See GNUPro Tools for Embedded Systems to locate the following documentation, which discusses porting the GNU development tools to the Win32 host while exploring the development and architecture of the Cygwin library.
Cygwin was invented in 1995 by Cygnus as part of the answer to the question of how to port the GNU development tools to a Win32 host. The Win32-hosted GNUPro compiler tools that use the Cygwin library are available for a variety of embedded processors as well as a native version for writing Win32 applications.


Cross-development environment

Using GNUPro Toolkit in one of the cross-development configurations usually requires some attention to setting up the target environment.
A cross-development configuration can develop software for a different target machine than the development tools themselves (which run on the host)—for example, a SPARCstation can generate and debug code for a Motorola Power PC-based board. This process is known as embedded development.
For GNUPro tools to work with a target environment (except for real-time operating systems, which provide full operating system support), set up the tools with the help of the following documentation.


The C run-time environment (crt0)

To link and run C or C++ programs,  you need to define a small module (usually written in assembler as ‘crt0.s’) to ensure that the hardware initializes for C conventions before calling main.
There are some examples available in the sources of GNUPro Toolkit for ‘crt0.s’ code (along with examples of system calls with sub-routines).
Look in the following path.
installdir/gnupro-99r1/src/newlib/libc/sys
installdir refers to your installation directory, by default ‘/usr/cygnus’.
For example, look in ‘.../sys/h8300hms’ for Hitachi H8/300 bare boards, or in ‘.../sys/sparclite’ for the Fujitsu SPARClite board.
More examples are in the following directory.

  
installdir/gnupro-99r1/src/newlib/stub
To write your own crt0.s module, you need the following information about your target.
At a minimum, your crt0.s modulemust do the following processes.
A more complete ‘crt0.s’ module might also do the following processes.

crt0, the main startup file

The crt0 (C RunTime 0) file contains the initial startup code.
Cygnus provides a crt0 file, although you may want to write your own crt0 file for each target.

The crt0 file is usually written in assembler as crt0.S, and its object gets linked in first and bootstraps the rest of your application.

The crt0 file defines a special symbol like _start, which is both the default base address for the application and the first symbol in the executable binary image.

If you plan to use any routines from the standard C library, you’ll also need to implement the functions on which libgloss depends. The crt0 file accomplishes the following results.
 

See also I/O support code.

The linker script

In the following path, find the example linker scripts (hosttype signifies your host configuration and targettype signifies the embedded configuration to which you target): 
/usr/cygnus/hosttype/targettype/lib/ldscripts/
In that directory, there will be files with the .x, .xbn, .xn, .xr, .xs, and .xu extensions. These are examples of linker scripts.

The linker script accomplishes the following processes to result.

There are two ways to ensure the memory map is correct.
The following is an example of a linker script for an m68k-based target board.
The following discusses setting up constructor and destructor tables for g++.

Set up the .text section, using the following example's input.

     
In a coff file, this is where all of the initialized data goes. The default values for _bss_start and _end are set here for use by the crt0 file when it zeros the .bss section.

I/O support code

Most applications use calls to the standard C library. However, when you initially link libc.a, several I/O functions are undefined. If you don't plan on doing any I/O, you're OK; otherwise, you need to create two I/O functions: open() and close(). These don't need to be fully supported unless you have a file system, so they are normally stubbed out, using kill().
sbrk()is also a stub, since you can't do process control on an embedded system, and it is only needed by applications that do dynamic memory allocation. It uses the variable, _end, which is set in the linker script.
The following routines are also used for optimization.

Memory support

The following routines are for dynamic memory allocation.

Miscellaneous support routines

The following support routines are called by newlib, although they don't apply to the embedded environment.

Source-Navigator demonstration

The following documentation discusses the Source-Navigator source code comprehension tool, using a tutorial to demonstrate the usage of debugging the sources for a project, editing the source files and building the project, the monopgame. In this tutorial, you will create two targets, monop and initdeck, and, with them, use many compiling, editing and debugging features of GNUPro Toolkit. The result is making and running the monopproject’s game.
Invoke Source-Navigator with the following input, using a shell window’s commandline interface from the /usr/cygnus/gnupro/sn99r1/directory. For more information about using Source-Navigator, see its online documentation from its Help menu.

Creating the Source-Navigator demonstration project

 
With Source-Navigator active, create a new project.
    1. Choose File -> New Project... from the Symbol Browser and define a new project, calling it monop.proj.
    2. Under Add Directory, click the “...” button to select the demos\monop directory. See Figure 4 for the result of defining the new project’s name in the Auto-Create Project window. Click OK to build the project.
Figure 4: Creating a new project, monop.proj, from the demos\monop directory


Building the monop target

Having created a project, you must then build its target components.
    1. Choose Tools -> Build Settings... to start the Build Settings window.
    2. Enter monop as the name of the target. See Figure 5 for the result.
Figure 5: Creating a monop target


3. Click Create. The Edit Target window appears.
4. In the Build Directory field, click the “...” button and select the build directory for the monop project (see Figure 6).
Figure 6: Defining the project for building


5. From Project Files in the Edit Target window for the monop project, select cards.c, execute.c, getinp.c, houses.c, jail.c, misc.c, monop.c, morg.c, print.c, prop.c, rent.c, roll.c, spec.c, and trade.c files.
6. Click the Add Files button to copy the files to the Target Files list. In Figure 7, see the result of moving the files from the Target Files pane to the Project Files pane.
Figure 7: Adding the project’s files to the target


NOTE:
To execute the program correctly in UNIX, click the Link Rules tab. Enter xterm -e bmonop in the Command to launch Application field and click OK to close the Link Rules window.
7. Click OK to close the Edit Targetwindow. Click Done to close the   Settings window. The target is created. Now you need to debug and compile the program. See Debugging and compiling the monop target.

Debugging and compiling the monop target

To ensure that a project can compile (or build), you must first run through a debugging process before using the maketool to create the project.
    1. Select Tools -> Build from the menu bar. The Buildwindow opens.
2. In Build Targets, select monop from the target list. See Figure 8. Click Start.
Figure 8: Running a debugging process for the project before compiling


3. In this tutorial, Source-Navigator generates some errors from the build. For instance, lint needed to have a definition in the source code. See Figure 9.
Figure 9: Errors in the project


Creating the lint macro

To ensure that a project can build, edit the macro errors that the debugger finds.
    1. Choose Tools -> Build Settings... to start the Edit Target window. See Figure 10.
2. Double-click monop to edit it.
3. Click the Build Rules tab to modify the rules for the build.
Figure 10:  Modifying how the project builds


4. Because monop is written in C, double-click the C rule in the File Type column. The Build Rules Settings window appears.
5. Click the Defines tab. Enter lint in the text entry box. See Figure 11.
Figure 11: Defining the lint macro


6. Click New to create the macro.
7. Click OK to close the Build Rules Settings window. Click OK to close the Edit Target window. Click Done to close the Build Settings window.
8. Select Tools -> Build from the menu bar and select monop from the target list.
9. monop generates without errors. However, at runtime the program does not run because we still need to define the path to the cards pack.

Creating the _PATH_CARDS macro

Now, define the other macro, _PATH_CARDS, to continue making the project work.
    1. Choose Tools -> Build Settings... to start the Edit Target window.
2. Double-click monop to edit it.
3. Click the Build Rules tab to modify the rules for the build. See Figure 12.
Figure 12: Modifying the project’s macros


4. Because monop is written in C, double-click the C rule. The Build Rules Settingswindow appears, as in Figure 13.
5. Click the Defines tab.
6. Enter the following input in the dialog below the Macro defines pane, replacing <project directory> with your path to the demos\monop directory:
_PATH_CARDS= " \ " <project directory>/cards.pck\ ""
Figure 13: Re-defining a project’s macro


    Now, GNUPro Toolkit uses an appropriate definition for the card pack macro, _PATH_CARDS, when running the monop program.
7. Click OK to close the Build Rules Settings window. Click OK to close the Edit Target window. Click Done to close the Build Settings window.
8. Select Tools -> Build from the menu bar and select monop from the target list. Click Start to perform the build.
9. _PATH_CARDS="\"<build directory>/cards.pack\""  is a macro. To ensure that this change is picked up at compile time, perform a clean build of the monop target project by selecting Tools->Clean Build in the Build window (see Figure 14).
A clean build is equivalent to the make clean command.
Figure 14: Performing a clean build for a project


10. Click the Start button to perform the build.
11. Now, the monop project compiles without errors (see Figure 15).
Figure 15: A clean build of a project


Building the initdeck target

Next, you need to create another target to initialize the cards in the monop game.
    1. Choose Tools -> Build Settings... to invoke the Build Target window.
2. Enter initdeck as the name of the target (see Figure 16).
Figure 16: Defining another target for a project


Click Create. The Edit Target window appears (see Figure 17).
In the Build Directory field, click the “...” button and select the monop directory.
From Source Files, select the initdeck.c file and click the Add Filesbutton to copy the file to the Target Files list.
Figure 17: Creating a new target for a project


Click OK to close the Edit Target window. Click Done to close the Build Settingswindow, having defined and created the new target.

Debugging the initdeck target

To ensure that a project can build with the new target, edit the macro errors that the debugger finds.
    1. Build the target by selecting Tools -> Build from the menu bar of the Build window. Select initdeck from the target list, and click Start.
2. initdeck generates with errors. Again, we need to define the lint macro and the path to the cards.
3. Choose Tools -> Build Settings... to start the Build Settingswindow.
4. Double-click initdeck to edit it.
5. Click the Build Rules tab. Double-click the C rule. The Build Rules Settings window appears (see Figure 18). Click the Defines tab. Enter lint in the text entry box.
Figure 18: Defining the lint macro for the new target


6. Click New to create the macro. Enter the following input in the dialog below the Macro defines pane, replacing <project directory> with your path to the demos\monop directory (see Figure 19 as an example):
_PATH_CARDS= " \ " <project directory>/cards.pck\ ""
Figure 19: Defining the path for the new target


    Now, GNUPro Toolkit uses an appropriate definition for the card pack when running the monop program.
Click OK to close the Build Rules Settings window. Click OK to close the Edit Target window. Click Done to close the Build Settings window, having modified the target for the project.
Open a shell window and copy the cards.inp file in the demos\monopdirectory into the build directory (see Figure 20 for an example of the copy command in a Command.com shell window that a Windows NT developer could use; UNIX users would use the cp command in a shell window).
Figure 20: Copying files for the project in a shell window


Select Tools-> Build from the menu bar and select initdeck from the target list.
To ensure that the macro changes are picked up at compile time, perform a clean build of the initdeck target by selecting Tools -> Clean Build (see Figure 21).
Figure 21: Performing a clean build for the new target for the project


Click the Start button to perform the build.
Now, initdeck compiles and links without errors. binitdeck is the name of the working executable.
Click the Run button to run binitdeck which creates the cards used in the game.
A shell window opens to build the cards (see Figure 22) and closes after the build is complete.
Figure 22: Rebuilding the new target for the project


From the Build Targets field of the Build window, select monop and click Run.
A shell window opens and monop runs automatically. Enter the number of players and their names. See Figure 23 for an example in a shell window of a project that builds and is ready to run.
Use the ? key to get playing options for monop. Oh, have fun.
Figure 23: A built project that's ready to run


Top|Contents|Previous|Next