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.
For our tools to work with
a target environment (except for real-time operating systems, which provide
full operating system support), set up the tools by using 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') that makes
sure the hardware is initialized for C conventions before calling main.
There are some
examples of crt0.s code (along with examples of system call stub
code) available in the source code for GNUPro Toolkit. Look
in the following path.
installdir /gnupro-98r1/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-98r1/src/newlib/stub
To write
your own crt0.s module, you need the following information about
your target.
-
A memory map. What memory is
available, and where?
-
Which way does the stack grow?
-
What output format do you use?
At a minimum,
your crt0.s module must do the following processes.
-
Define the symbol, start
(_start in assembler code).
Execution begins at this symbol.
-
Set up the stack pointer,
sp.
It is largely up to you to choose where to store your
stack within the constraints of your target's memory map. Perhaps the simplest
choice is to choose a fixed-size area somewhere in the uninitialized data
section (often called 'bss'). Remember that whether you choose
the low address or the high address in this area depends on the direction
your stack grows.
-
Initialize all memory in
the uninitialized-data (bss) section to zero.
The easiest way to do this
is with the help of a linker script (see Linker
scripts in Using ld
in GNUPro Utilities). Use a linker script to define symbols
such as 'bss_start ' and 'bss_end' to record the
boundaries of this section; then you can use a 'for' loop
to initialize all memory between them in the 'crt0.s' module.
-
Call main.
Nothing else will!
A more complete
crt0.s module might also do the following processes.
-
Define an _exit
subroutine.
This is the C name; in your assembler code. Use the label,
__exit, with two leading underbars. Its precise behavior depends
on the details of your system, and on your choice. Possibilities include
trapping back to the boot monitor, if there is one; or to the loader,
if there is no monitor; or even back to the symbol, start.
-
If your target has no monitor
to mediate communications with the debugger, you must set up the hardware exception
handler in the crt0.s module.
See The
gdb remote serial protocol in Debugging
with GDB in GNUPro Debugging Tools for details on
how to use the gdb generic remote-target facilities for this purpose.
-
Perform other hardware-dependent
initialization.
For example, initialize an mmu or an auxiliary
floating-point chip.
-
Define low-level input
and output subroutines.
For example, the 'crt0.s' module is a convenient
place to define the minimal assembly-level routines described in System
calls in GNUPro
C Library in GNUPro Libraries.