The complete tool name is a four-part hyphenated string. The first part indicates the processor family (‘mips’). The second part indicates the processor (‘tx39’). The third part indicates the file format output by the tool (‘elf’). The fourth part is the generic tool name (‘gcc’). For example, the GCC compiler for the Toshiba TX39 is ‘mips-tx39-elf-gcc’.

The TX39 package includes the following supported tools:

Toshiba JMR-TX3904A-50 evaluation board

Both targets run in big-endian mode.

C:\cygnus\gnupro\i386-cygwin32\mips-tx39-elf\ecos-98r1p6
 

For Bourne shell compatible shells:
 

-msoft-float

__mips__
__R3000__

static object_t myobj __attribute__((init_priority (30000) ));

The syntax is slightly different if the object takes any arguments to its constructor:

static object_t myobj __attribute__((init_priority (30000) )) = object_t(arg1, arg2);

The numeric priority can be from 1 to 65535, with 1 being the highest priority, and 65535 being the lowest. The default priority for objects without this attribute is 65535. Constructors with a higher priority are guaranteed execution before constructors with lower priority.

In all cases, you must provide the argument ‘-finit-priority’ to the compiler on its command-line for it to recognize this attribute when you are compiling your C++ source files.

If you are using eCos, be warned that eCos uses initialization priorities internally. Ensure you choose an appropriate priority level so that other eCos subsystems will have initialized before you refer to them in your own constructor.

The GNUPro C and C++ compilers can now optionally remove these unnecessary functions from the final image. They also ensure that any shared global data is removed that is only referenced by functions that are removed. This can be done by including the options ‘-ffunction-sections’ and ‘-fdata-sections’ on the command-line, when you invoke the C or C++ compiler. The ‘-ffunction-sections’ option removes unnecessary functions, and the ‘-fdata-sections’ option removes unnecessary data.

In addition, when classes define virtual methods in C++, it is possible to remove any unused methods from the final image by passing the option ‘-fvtable-gc’ to the C++ compiler on its command-line.

In all cases, you must also supply a command-line option when linking. If invoking the linker ld directly, use ‘--gc-sections’ on its command-line; alternatively, if you are using the preferred method of linking your executable, using the form
‘gcc -o <program name> <file1>.o <file2>.o’, then also pass the option ‘-Wl,--gc-sections’ on the compiler command-line, for example:
 

* If no ‘alloca’ region the frame pointer (FP) points to the same place as SP.
 

Stack frames for functions that take a variable number of arguments look like this:

* If no ‘alloca’ region the frame pointer (FP) points to the same place as SP.

DOUBLE OR FLOAT:

If ‘FR > f19’, go to ‘STACK’. Otherwise, load the parameter value into
floating-point register ‘FR’ and advance ‘FR’ to the next floating-point register (or register pair in 32-bit mode). Then go to ‘SCAN’.

SIMPLE ARG:

A SIMPLE ARG is one of the following:

LONG LONG in 32-bit mode:

If ‘GR > r10’, go to ‘STACK’. Otherwise, if ‘GR’ is odd, advance ‘GR’ to the next register. Load the 64-bit ‘long long’ value into register pair ‘GR’ and ‘GR+1’. Advance ‘GR’ to ‘GR+2’ and go to ‘SCAN’.

STACK:

Parameters not otherwise handled above are passed in the parameter words of the caller's stack frame. SIMPLE ARGs, as defined above, are considered to have size and alignment equal to the size of a general-purpose register, with simple argument types shorter than this sign- or zero-extended to this width. float arguments are considered to have size and alignment equal to the size of a floating-point register. In 64-bit mode, floats are stored in the low-order 32 bits of the 64-bit space allocated to them. ‘double’ and ‘long long’ are considered to have 64-bit size and alignment. Round ‘STARG’ up to a multiple of the alignment requirement of the parameter and copy the argument byte-for-byte into ‘STARG’, ‘STARG+1’, ... ‘STARG+size-1’. Set ‘STARG’ to ‘STARG+size’ and go to ‘SCAN’.

Copies of large structs are made under the following rules:

The varargs macros set up a two-part register save area, one part for the general-purpose registers and one part for floating-point registers, and maintain separate pointers for these two areas and for the stack parameter area. The register save area lies between the caller and callee stack frame areas.

In the case of software floating-point only the general-purpose registers need to be saved. Because the save area lies between the two stack frames, the saved register parameters are contiguous with parameters passed on the stack. This allows the varargs macros to be much simpler. Only one pointer is needed, which advances from the register save area into the caller's stack frame.

The symbols ‘$0’ through ‘$31’ refer to the general-purpose registers.

The following symbols can be used as aliases for individual registers:

R1 R2 R3 - integer registers

I1 I2 I3 - immediate integers

I? - integer value dependent on values of macro arguments

There are two ways for GDB to talk to a TX39 target.

In some operating systems, such as eCos, a single program may have more than one thread of execution. The precise semantics of threads differ from one operating system to another, but in general the threads of a single program are akin to multiple processes, except that they share one address space (that is, they can all examine and modify the same variables). On the other hand, each thread has its own registers and execution stack, and perhaps private memory.

GDB provides the following functions for debugging multi-thread programs

• ‘thread threadno’, a command to switch among threads
• ‘info threads’, a command to inquire about existing threads
• ‘thread apply [threadno][all] args ’, a command to apply a command to a list of threads
• thread-specific breakpoints

info threads

When your program has multiple threads, you can choose whether to set breakpoints on all threads, or on a particular thread.
 

If you do not specify ‘thread <threadno>’ when you set a breakpoint, the breakpoint applies to all threads of your program.

You can use the thread qualifier on conditional breakpoints as well; in this case, place ‘thread <threadno>’ before the breakpoint condition, as the following example shows.
 

Conversely, whenever you restart the program, all threads start executing. This is true even when single stepping with commands like ‘step’ or ‘next’. In particular, GDB cannot single-step all threads in lockstep. Since thread scheduling is up to your debugging target’s operating system (not controlled by GDB), other threads may execute more than one statement while the current thread completes a single step. In general other threads stop in the middle of a statement, rather than at a clean statement boundary, when the program stops.

You might even find your program stopped in another thread after continuing or even single stepping. This happens whenever some other thread runs into a breakpoint, a signal, or an exception before the first thread completes whatever you requested.

Normally GDB does not attempt to interfere with thread scheduling. This means that in the default mode (‘scheduler-locking off’), the current thread may be scheduled out, and a different thread may begin running, at any time (as determined by the native scheduler). For instance, you may give a GDB command such as ‘step’ or ‘finish’, and when the command completes, you may be looking at a different thread.

If you set the scheduler-locking mode to ‘step’, then GDB will try to interfere with the native scheduler just enough to prevent another thread from popping up while you debug. Other threads may get to run sometimes, but whenever a command such as ‘step’ or ‘finish’ completes, you should be looking at the same thread that was running before the command. Of course, if another thread gets to run and hits a breakpoint, GDB will still switch you to that thread (so if you don’t want that to happen, then disable your breakpoints).

For even greater (and more intrusive) control over the thread scheduler, GDB provides the mode ‘scheduler-locking on’. In this mode, the native scheduler is completely locked, and no thread may run except the current one. Obviously this will radically change the behavior of your program, and may lead to deadlock or other unpleasant consequences, so use it with caution.

Syntax:

set scheduler-locking [off on step]

The TX39 simulator is not designed to match timing characteristics of its target board. For example, the CPU module uses a single clock cycle for all instructions, its memory is infinitely fast, and its simulated serial I/O is infinitely fast. Furthermore, a number of obscure or inapplicable functions were omitted from the simulated peripherals. The simulator is just complex and accurate enough to run eCos programs.

The user program is provided with a single 32mb block of memory at address ‘0xa0000000’ (shadowed at address ‘0x80000000’).

--board=BOARD