Tornado Reference : Tornado Files Description

architecturedb

NAME

architecturedb - Target Architecture description database

SYNOPSIS

$(WIND_BASE)/resource/target/architecturedb

DESCRIPTION

This file describes the informations related to a given target systam which are required by the target server. This file has to be updated when a new CPU support is added. Those informations are of two kinds :

Target related informations

Target Operating System and processor informations.

Host related informations

Target system tools informations.

OVERALL ORGANIZATION

This file is organized into sections. A section is a set of lines following a Section Name. A Section Name is a line starting by `[' and ending by `]'. For instance :

[section 1]
variable1 = var1
; comment
variable2 = var2
...
[section 2]
...

A comment is a line beginning by the `;' character.

Each section defines a number of variables settings. The syntax is :

variable name = <variable value>

variable name represents a name for a parameter.

<variable value> represents the value assigned to the parameter. the parameter's value is taken from the first non space character following the `=' until the end of the line.

The target architecture informations are organized into four section types :

[misc] section

represents some target independent informations. We find here :

cplusplus

The C++ static constructors and destructors loader/unloader DLL name.

[CpuFamilyName] sections

In those sections are stored informations relatives to CPU families. We find here :

cpuFamily

CPU family ID (used for backward compatibility)

Memory alignment

Gives the memory alignment for this CPU family. This parameter can be overridden by the CPU specific declaration.

Object File Type

OMF (one or many) supported for this family. If many OMF are supported, they must be comma separated (ex: Object File Type =elf,coff,a.out). This information is used to build the OMF reader DLL name.

ExtentionName

The extension name used for this family. This value is used to build the relocator library name and routines.

Architecture Directory

Extension used to access the source files under target/src/arch for this CPU family.

Leading Character

Character prepended by the compiler before each symbol. If this parameter is ommitted, no symbol's leading char is assumed. Notation like \x1 or 2 hex digits can be used to code a non printable char. The character \x0 means that no leading char is used.

CoreFile Offset

CoreFile offset to skip for performing checksum (used only for X86 family only). Hexadecimal notation (i.e. 0x1234) are handled.

[CPU_<CPU_Id>] sections

In those sections are stored informations relatives to a specific CPU (whose Id is CPU_Id in decimal form, and is given by the target during the attach phase) . We find here :

cpuname

name of the CPU (printable form).

cpuFamilyName

CPU family name (printable form) to which its belongs.

Thumbing

Tells whether or not thumb mode is enabled for this CPU (ARM processors only).

Memory alignment

Gives the memory alignment for this specific CPU. This parameter is optional. If present, it overrides the CPU family declaration.

[OS_<OS Id>] sections

In those sections are stored informations relatives to the OS running on the target. We find here :

osName

Name (printable form) of the Operating System running on the target.

redirectRoutineName

Name of the target routine to call to perform an I/O redirection (used by the target server to redirect VIO to a console). On vxWorks it is ioGlobalStdSet (). If not present, the target server won't be able to automatically redirect the VIO to its console (see option -r in tgtsvr).

openRoutineName

Name of the target routine to call to perform an open () operation. If not present, the target server won't be able to open a VIO on the target.

allocRoutineName

Name of the target routine to call to perform a malloc () operation. If not present, the target server won't be able to extend its memory pool.

semGiveRoutineName

Name of the target routine to call to perform a semGive () operation. If not present, the target server won't be able to run the "Target Server File System" facility.

shellTaskName

Name of the shell task running on the target (if any). This field is used to redirect the shell I/O in the target server default virtual Console (See option -redirectShell in tgtsvr (1)). If not present, the target server won't be able to redirect target shell I/O.

taskNameToIdRoutineName

Name of the target routine to call to perform a taskNameToId () operation. If not present, the target server won't be able to redirect target shell I/O.

shellOrigStdSetRoutineName

Name of the target routine to call to perform a shellOrigStdSet (). If not present, the target server won't be able to redirect target shell I/O.

taskRestartRoutineName

Name of the target routine to call to perform a taskRestart (). If not present, the target server won't be able to redirect target shell I/O.

If no such section exists for the OS running on the target, the target server will default to an "unknown" OS and will not be able to perform any routines decribed in this section on the target.

HOW THE TARGET SERVER USES THIS FILE

Lets take an example. We have the following file organization :

[misc]
cplusplus = cpluslib
[MC680X0]
cpuFamily = 9
Object File Type = a.out
ExtentionName = 68k
Architecture Directory = m68k
Memory alignment = 4
Leading Character = _
[CPU_1]
cpuname = MC68000
cpuFamilyName = MC680X0
[OS_1]
osName = VxWorks
Compiler = gnu
redirectRoutineName = ioGlobalStdSet
openRoutineName = open
allocRoutineName = malloc
semGiveRoutineName = semGive
shellTaskName = tShell
taskNameToIdRoutineName = taskNameToId
shellOrigStdSetRoutineName = shellOrigStdSet
taskRestartRoutineName = taskRestart

After connecting the target, the target server asks for its identity. It receives then a description header where the CPU and OS Ids are coded in. For our example the CPU Id and OS Id are equal to 1. The target server will parse this file as follow : look in the [CPU_1] section to find the CPU Family name. Then will go into the [MC680X0] section to find the related informations. It then comes back to the [CPU_1] section to see if some parameters have been overridden (Memory alignment). Then the target server will check the [OS_1] section to get the OS specific routines. The target server will then load the following DLLs (see : API Guide: Object Module Loader for loader/relocator library and routines names coding convention.)

loadAout

for the OMF reader,

aout68k

for the relocator,

dsm68k

for the disassembler,

cplusplus

for the C++ static constructors and destructors loader/unloader

NOTE

 The DLL extension are host specific (e.g. loadAout.`so' on Solaris).

SEE ALSO

architecturedb, API Guide: Object Module Loader for loader/relocator library and routines names coding convention. tgtarch