The following documentation discusses
the NEC V850 family of processors for GNUPro tools.
For more specific information on the V850
processor, see V850 User's Manual, V851 Hardware User's
Manual (NEC document #U10954EU1V0UM00, January 1996), V850_EVA
(Revision C), and System V Application Binary Interface (Prentice
Hall, 1990).
Toolchain
features for V850
The following documentation describes the
main features of the tools addressing the V850 family of processors.
The V851 version of the V850 family of
processors is supported with the GNUPro tools.
The V850 tools support the ELF object
file format. To produce S-records, use the GNU
linker, ld (see Using ld
in GNUPro Utilities for more information) or objcopy
(see Using binutils
in GNUPro Utilities for more information).
For the V850 processor, file names are
case sensitive under Unix. Case sensitivity for Windows 95 and Windows
NT is dependent on system configuration. By default, file names under Windows
95 and Windows NT are not case sensitive for the V850 processor.
The following case sensitive issues under
Unix, Windows 95, and Windows NT apply to the V850 processor.
-
command line options
-
assembler labels
-
linker script commands
-
section names
The following case sensitive issues under
Unix, Windows 95, or Windows NT do not apply to the V850 processor.
-
GDB commands
-
assembler instructions and register names
GNUPro Toolkit includes tools for converting
legacy source code, originally written for other compilers, into GNUPro
compiler (GCC) compliant code.
For the Windows 95/NT toolchain, the
libraries install in different locations. Therefore, the Windows 95/NT
hosted toolchain requires the following environmental settings to function
properly. Assume the release is installed in C:\USR\CYGNUS . The
<yymmdd> variable indicates the release date found on
the CD.
SET PROOT=C:\usr\cygnus\V850-<yymmdd>
SET PATH=%PROOT%\H-i386-cygwin32\BIN;%PATH%
SET GCC_EXEC_PREFIX=%PROOT%\H-i386-cygwin32\lib\gcc-lib\
SET INFOPATH=%PROOT%\info
REM Set TMPDIR to point to a ramdisk if you have one
SET TMPDIR=%PROOT%
Note:
The trailing back slash ( \ ) in ` GCC_EXEC_PREFIX
' is necessary.
Programs may be developed for and debugged
on the GNUPro Instruction Set Simulator. The ICE (In-circuit Emulator)
for V851
is in development.
The complete tool name is a three-part
hyphenated string. The first part indicates the processor or processor
family (V850). The second part indicates the file format output
by the tool (elf). The third part is the generic tool name (gcc).
For example, the GCC compiler for the NEC V850 family of processors is
V850-elf-gcc.
The V850 package includes the following
supported tools.
Tool Description
|
Tool Name
|
GCC compiler
|
V850-elf-gcc
|
G++ compiler
|
V850-elf-g++
|
C++ compiler
|
V850-elf-c++
|
C++ demangler
|
V850-elf-c++filt
|
GNU assembler
|
V850-elf-as
|
GNU linker
|
V850-elf-ld
|
Standalone simulator
|
V850-elf-run
|
Binary utilities
|
V850-elf-ar
V850-elf-nm
V850-elf-objcopy
V850-elf-objdump
V850-elf-ranlib
V850-elf-size
V850-elf-strings
V850-elf-strip |
GDB debugger
|
V850-elf-gdb
|
Cygnus Insight, the GNUPro visual debugger
(Windows 95/NT only) |
V850-elf-gdbtk
|
Important:
The binaries for a Windows 95/NT hosted toolchain are
installed with an .exe suffix. However, the .exe suffix
does not need to be specified when running the executable.
The following documentation discusses the
ABI for the V850 processor.
Data
types and alignment for V850
The following table describes the data types and their
alignment sizes for the V850 processor.
char :
|
1 byte
|
short :
|
2 bytes
|
int :
|
4 bytes
|
long :
|
4 bytes
|
long long :
|
4 bytes
|
float :
|
4 bytes
|
double :
|
4 bytes
|
long double :
|
8 bytes
|
pointer :
|
4 bytes
|
The stack is aligned to a four byte boundary.
One byte is used for characters (including structure/unions made entirely
of chars), and two byte alignment for everything else. Basic data
types shorter than a word are promoted to a word when passed as arguments
or return values.
Calling
conventions for V850
GCC will use up to four registers for passing
parameters (r6 through r9). A parameter may be split
between registers and memory if it does not fit within the remaining available
parameter registers. Alignment of parameters within the parameter list
is the same as their basic alignment. This implies that doubles
and long long types need not be 8-byte aligned in parameter lists.
Calling a varargs or stdarg
function does not change how parameters are passed. However, the callee
will flush all parameter registers back to a caller allocated parameter
flush back area in the stack. This allows the callee to then treat all
parameters as if they had been passed in the stack. The caller is responsible
for allocating the 16-byte parameter flush back area at the bottom of the
current stack. The callee is free to use that 16-byte area for any purpose
in a non-varargs or a non-stdarg function.
Structures greater than 8 bytes in length,
passed by value, are automatically converted into pass-by-invisible-reference
structures (i.e., the compiler arranges to pass a pointer instead of the
entire structure). The callee must make a copy of the structure if the
callee modifies the pass-by-invisible reference structure.
Values are returned in the same manner
as the GHS compilers, including the use of r6 as a return-structure-pointer
when returning large structures. r31, also known as lp
(link pointer), is used as a return pointer during a call instruction;
the callee is responsible for saving r31 into the stack if the
callee performs any additional function calls or uses r31 as a
scratch register.
Stack arguments are located at increasing
addresses from entry_sp. The varargs flush back area
uses:
entry_sp (r6)
entry_sp + 4 (r7)
entry_sp + 8 (r8)
entry_sp + 12 (r9)
The callee can use the flush back area
for any purposes if the callee does not use varargs or stdarg
facilities.
Register
allocation for V850
Fixed registers are never available for
register allocation in the compiler. By default the following registers
are fixed in GCC: r0 (zero), r1 and r3 (sp),
r4 (gp), r30 (ep). Caller saved registers can be used
by the compiler to hold values that do not live across function calls.
The caller saved registers are r2, r5 through r19,
and r31. Callee saved registers retain their value across function
calls. The callee saved registers are r20 through r2
.
Note:
r6 through r9 are parameter registers
while r10 and r11 are function return registers. r31
is the return pointer.
r29 is used as the frame pointer
in some functions.
GCC will always create a frame pointer
when not optimizing. The frame pointer will be eliminated when optimizing,
except for functions which allocate dynamic stack space (functions which
call alloca). Interrupt functions can never have a frame pointer;
so, when compiling an interrupt function, you must either specify optimization
(using the -O option) or by explicitly making the compiler not
generate a frame pointer (by using the -fomit-frame-pointer option).
Interrupt functions can not use alloca calls, nor can they have
very large stacks (less than 32K, in size).
Stack
frame information for V850
The following documentation discusses the
stack frame for the V850 processor's usage, especially for the debugging
processes. See stack frame and also stack
frames for functions taking a variable number of arguments.
-
The stack grows downwards from high addresses to low addresses.
-
A leaf function need not allocate a stack frame if it doesn't
need one.
-
A frame pointer need not be allocated.
-
The stack pointer shall always be aligned to 4 byte boundaries.
-
The register save area shall be aligned to a 4 byte boundary.
* FP
points to the same location as SP. |
Stack frames for functions that take a
variable number of arguments have usage as shown by Stack
frames for functions taking a variable number of arguments.
* FP
points to the same location as SP. |
Argument
passing for V850
Arguments are passed to a function using
(1) registers and (2) memory, if the argument passing registers are depleted.
Each register is assigned an argument until all are used. Unused argument
registers have undefined values on entry. Use the following rules.
-
Quantities of size 8 bytes or less are passed in registers
if available, then as memory. Larger quantities are passed by reference.
Arguments passed by reference are passed by making a copy of the argument
on the stack and passing a pointer to that copy.
-
If a data type would overflow the register arguments, then
it is passed in registers and memory. A long long data type passed
in r9 would be passed in r9 and in the first 4 bytes
of the stack.
-
Arguments passed on the stack begin at sp with respect
to the caller.
-
Each argument passed on the stack is aligned on a 4 byte
boundary.
-
Space for all arguments is rounded up to a multiple of 4
bytes.
-
The first argument register is r6.
-
The last argument register is r9.
-
A call to a function, procedure, or subroutine uses a jarl
routine, a lp instruction which saves the return address in r31
(lp). The return uses a jump[r31] instruction.
Function
return values for V850
Scalar or pointer return values are returned
in r10 and sign-extended or zero-extended to 32 bits for types
smaller than 32 bits.
-
32-bit floating point values are returned in r10.
-
64-bit floating point values are returned in the register
pair, r10 and r11.
To call a function which returns a structure
or union in C and C++, the address of a temporary of the return type is
passed by the caller in r6. The function returns the structure
value by copying the return value to the address pointed to by r6,
and copies r6 into r10 before returning to the caller.
The following documentation discusses the
ABI for the V850 processor.
V850-specific
command-line options for GCC
For a list of available generic compiler
options, see GNU CC command options in Using GNU CC in GNUPro
Compiler Tools.
The V850-specific command-line options are supported.
-mep
-mno-ep
Enables (disables) the checking of pointers in the basic
blocks and if a pointer is heavily used, it will copy the pointer into
the Element Pointer (r30) so it can use the shorter SLD
and SST instructions for that basic block. The default is -mep
when optimization is on.
-mprolog-function
-mno-prolog-function
Enables (disables) the use of external functions to save
and restore the registers in the function prologue. The default is -mprolog-function
when optimization is on.
For more detailed information on the use of the following
three compiler options, see Special
data areas on the V850.
-msda= <n>
Enables automatic placement of static / global data in
the small data area (sda) off of Global Pointer (r4).
This enables data access with one instead of two 32-bit instructions.
-mtda= <n>
Enables automatic placement of static/global
data in the tiny data area (tda) off of Element Pointer
(r30). This enables data access with one 16-bit instruction instead
of two 32-bit instructions.
-mzda= <n>
Enables automatic placement of static / global data in
the zero data area (zda) off of Zero Register (r0).
This enables data access with one instead of two 32-bit instructions.
Preprocessor
symbols for V850
By default, the compiler defines the preprocessor
symbols as __v850__, __v851__, and __v850.
Special
data areas on the V850
There are 3 distinct data areas on the V850: zda
(zero data area), sda (small data area), and tda (tiny
data area).
-
zda variables are stored in the .zdata
and .zbss sections, which together must be no more than 64K bytes,
unless the bottom area of the address map is reserved for an internal ROM/PROM
in which case the limit is 32K. The linker puts them in memory at negative
offsets of -1 to -32K from 0, and if no internal ROM/PROM is present, from
0 to +32K as well (so that the zero pointer, r0, can be used to
point to the variables).
-
sda variables are stored in the .sdata
and .sbss sections, which together must be no more than 64K bytes.
The runtime startup code is responsible for loading up the gp
global pointer with an address within the region.
-
tda variables are stored in the .tdata
section, which must be no more than 256 bytes. The runtime startup code
is responsible for loading up the ep elemenmt pointer with an
address within the region. The -mep switch also uses the ep
element pointer, but restores it after it is done.
It is also possible to use GCC attribute
extension to the C language to explicitly specify which data area will
contain a given variable. For example, the following declaration's syntax
will put the integer variable, fred, into the zero data area.
int __attribute((zda)) fred;
If no special attributes or switches are
used, it normally takes two 32-bit instructions to reference any global/static
variable (one to get the high bits of the address into a register, and
the other to do the memory reference). Both zda and sda
static/global references take one 32-bit instruction, while tda
references take one 16-bit instruction. Thus, you can put the most frequently
used variables in the tiny data area and put most of the remaining variables
into either the zero or small data areas to cut down on the size of the
code space.
The variable, <n> in
-mzda= <n>, -msda= <n>,
and -mtda= <n> compiler options indicates variable
size in bytes. Variables that aren't put into a specific section with an
attribute, and whose size is less than or equal to <n>
bytes, are put into the indicated data section. For -mtda= <n>,
the maximum for <n> is 256 bytes. For -mzda=
<n>, the maximum for <n> is 32768
bytes. The maximum for -msda= <n> is 65536
bytes. You can combine these switches, and the compiler first looks at
tda, then sda, and finally, zda. The following
example's input shows the appropriate declaration to provide.
-mtda=4 -msda=256
This combination would indicate all static
or global variables less than or equal to 4 bytes, which would become tda
references, while all static or global variables less than 4 and greater
than or equal to 256 bytes become sda references.
Consider the following code.
struct fred { int a, int b; };
int main (void) { return fred.a + fred.b; }
If compiled with no options, the compiler
will put the fred structure into the normal data section of the
program. This means that it will take two 32-bit instructions to fetch
the contents of fred.a, and another two 32-bit instructions to
fetch the contents of fred.b for the program. If the program is
compiled with a -msda=8 declaration, then the compiler will put
the fred structure into the small data area (since fred
is 8 bytes in length, and the -msda=8 option tells the compiler
to put all variables of size 8 or less into the small data area). Now it
will only take one 32-bit instruction to fetch fred.a, and one
to fetch fred.b for compiling. If the program had been compiled
with the -mtda=8 declaration, then fred would have been
put into the tiny data area, and fetching fred.a would have required
only one 16-bit instruction.
As an alternative, the following code has
been changed.
struct __attribute__ ((zda)) fred { int a; int b; };
int main (void) { return fred.a + fred.b; }
When this code is compiled (with or without
any special command line options), the fred structure is placed
into the zero data area and fetching either fred.a or fred.b
requires one 32-bit instruction apiece.
The default behaviour is to place variables
into the (ordinary) data section. Adding _attribute__ ((zda))
forces that particular variable to go into the zero data area, but has
no effect on other variables. Specifying -mzda= <n>
on the command line forces all variables whose size is less than or equal
to <n> bytes into the zero data area. It is up to the
programmer to determine what value to use for <n>. If
the value is too large, then too many variables will be put into the zero
data area and error messages will be produced by the linker (after all,
the zda only has room for 32K bytes of data).
depragmaize modifies source code
and associated header files. depragmaize converts uses of certain
pragmas in C code to uses of equivalent GCC attributes. Pragmas, often
used to implement vendor specific features, are in many circumstances very
difficult to maintain both in the compiler and in the source code that
maintains them. For those machine-specific features affecting declarations
or symbols, attributes are a much better way to implement these features,
again both for the compiler maintainer and for the source code maintainer.
GCC has a well defined mechanism for adding new attributes to the compiler.
For more information about GCC's attributes,
see Using GNU CC or
use the gcc.info on-line help file.
In order to convert a particular source
file, the source file must contain C code compilable by GCC (which, of
course, includes ANSI C code as well as any GCC extensions). depragmaize
only converts a limited set of pragmas; see Conversions
for a current list.
depragmaize is intended to be
simple to use. The following descriptions for suggestions of the conversion
process will answer most questions. For instance, see depragmaize
options for the options that depragmaize accepts.
#pragma ghs startXXX
#pragma ghs endXXX |
XXX is tda,
sda, or zda. depragmaize will add the __attribute__((section("tda")))
pragma to the appropriate symbols between the start and end pragmas.
If the -R option is specified, depragmaize will also
remove these pragmas from the source.
|
#pragma ghs interrupt
|
To the function containing the pragma,
__attribute__((interrupt)), depragmaize will add __attribute__((interrupt)).
If the -R option is specified, depragmaize will also
remove this pragma from the source.
|
To do the conversion,
depragmaize makes use of GCC to find all the parts of the source
that need changing. That's why the source code must be compatible with
the GCC compiler source code in order for depragmaize to convert
it. Unfortunately, most real source code is not just compilable. Usually,
some number of compile time options must be passed to the compiler in order
for the particular source code to be properly compiled by the compiler.
Also, source code is often compiled under a number of different sets of
compile time options to produce different executables. See the following
documentation for further discussion of such issues. In the simplest case
(if your source code is very simple) you would invoke depragmaize
as the following example declaration suggests (where <file.c>
is the name of the source code file to be converted).
depragmaize <file.c>
depragmaize and <file.c> must
be in the current working directory. depragmaize will convert
<file.c> and any header files that the <file.c>
includes, if those header files reside in the current working directory.
The actual conversions done are described in the following discussions.
depragmaize only converts files that are in the current working
directory unless the -d option is used. depragmaize will
save a copy of the unconverted source file in <file.c>save,
unless the -N option is used. Any number of source files can be
specified on a single invocation of depragmaize.
If a source file, or set of source files, uses header
files that are not in the current working directory, and those header files
also must be converted, specify with the -d option. For
instance, the following declaration specifies that depragmaize
should convert <file.c> and any headers used by <file.c>,
if those headers are in the current working directory or in another directory,
other_directory.
depragmaize -d other_directory file.c
Often your source code will require some
compile time options to successfully compile.
-c "-DMACRO1=1 -I../include_files" file.c
The previous declaration will pass -DMACRO1=1
and -I../include_files to GCC. Typically, the kinds of options
that will need to be passed to GCC will be -D options and -I
options. Someone familiar with building the source code involved will need
to determine the exact list of options required to compile that source.
Note:
Options like -O and -g are not required
for proper conversion, though it will not hurt the process if they are
specified.
For some source code, the list of symbols
actually seen by the compiler is affected by the options given to the compiler.
For instance, use the following example to generate symbol lists.
#ifdef MACRO1
int a;
#else
int b;
#endif
If MACRO1 is defined on the command
line, the compiler will see the symbol, a, but not b;
and the opposite if MACRO1 is not defined. depragmaize
can only convert code actually seen by the compiler. In a case like this
depragmaize must be invoked twice, once with MACRO1 defined,
once without such a declaration. Of course, if MACRO1 does not
make code converted, you need not use this definition. For some source
code, the actual conversion required will depend on the command line arguments.
The most likely example of this would be cases where the tokens of the
#pragmas changed, depending on the command line arguments. Unfortunately,
the complexity of the conversions required by these cases is beyond depragmaize's
ability to handle automatically. You will need to make these conversions
by hand first, and then let depragmaize handle the other more
common cases.
Finally, because of the possibility that
some source code may need to be run through depragmaize more than
once to effect complete conversion, and depragmaize does not remove
the pragma's from the source code until the -R option is specified.
If your source code does not need to be run through depragmaize
more than once, you can use -R on that invocation, otherwise use
-R on the last invocation.
The following documentation discusses the
depragmaize options. The following example shows the standard
approach for a depragmaize declaration.
depragmaize [options ...] file ...
Each file and any header files it includes
are converted.
Files and headers are only converted if
they reside in the current directory or a directory specified by the -d
option. For each file that is converted, and for which some change is actually
made, depragmaize will create a copy of the original unconverted
file under the name, XXX.save, where XXX
is the name of the converted file (so file.c is saved under
file.c.save). If XXX.save already exists, depragmaize
will not overwrite it, and simply does not do this copy. The -N
option tells depragmaize not to make these copies.
-V
-v
--version
Specifies that depragmaize should convert file.c
and any headers used by file.c, if those headers in the current
working directory, or in other_directory, are being used.
This option also causes somewhat more verbose messages to be printed.
-q
--quiet
--silent
Don't print warning and informational messages (only
print errors).
-n
--nochange
Don't actually convert the source files, just print messages
about what would be done.
-c "STRING"
--compiler-options "STRING"
Pass "STRING" as options to the compiler
during the compilation part of the conversion process.
STRING should be a space separated list
of options for the compiler used. Use the following example's declaration.
depragmaize -c "-DMACRO1 -DMACRO2" t1.c
-R
--remove_pragmas
This option causes depragmaize to remove the
pragmas from the source in addition to converting them attributes.
-d <DIRECTORY>
--directory <DIRECTORY>
Add <DIRECTORY> to the list of directories
containing files which can be converted. The current directory is always
on this list. Files are not converted unless they are in a directory on
this list.
-x <FILENAME>
--exclude <FILENAME>
Do not convert <FILENAME>.
-p <COMPILER>
--file_name <COMPILER>
Use <COMPILER> as the compiler for
the compilation part of the conversion process. By default, gcc
is used. <COMPILER> should be the name of an executable
and it must work with a version of GCC which is compatible with depragmaize.
This is only useful for specifying a a GNU compiler program that is compatible
with depragmaize, unless that is not on your PATH.
-N
--nosave
Don't keep a copy of the original source.
-k
--keep
Keep a copy of the intermediate file. Only useful for
debugging depragmaize.
Structure
conversion for V850
Structure conversion is done, using the
GCC offset-info option.
The -offset-info output-file option
simplifies access to C struct's from the assembler.
For each member of each structure, the
compiler will output a .equ directive to associate a symbol with
the member's offset in bytes into the structure.
The symbol itself is the concatenation
of the structure's tag name and the member's name, separated by an underscore.
This option will output to the specified output-file an assembler
.equ directive for each member of each structure found in each
compilation. The .equ directives for the structures in a single
header file can be obtained as follows, where m.h is the header
containing the structures, and m.s is where the directives are
output.
gcc -fsyntax-only -offset-info m.s -x c m.h
The following is a short example of output
produced by the -offset-info option.
input file (m.h, for example):
struct W {
double d;
int i;
};
struct X {
int a;
int b;
struct Y {
int a;
int b;
};
struct Y y;
struct Y yy[10];
struct Y* p;
};
output file (m.s, for example):
.equ W_d,0
.equ W_i,8
.equ Y_a,0
.equ Y_b,4
.equ X_a,0
.equ X_b,4
.equ X_y,8
.equ X_yy,16
.equ X_p,96
The -offset-info option has the
following caveats.
-
No directives are output for bit-field members.
-
No directives are output for members who's offsets (as measured
in bits) is greater than the word size of the host.
-
No directives are output for members who's offsets are not
constants. This can happened only in structures which use some gcc specific
extensions which allow for variable sized members.
Assembler
information for V850
The following documentation discusses the
assembler issues for the V850 tools.
For a list of available generic assembler
options, see Command-line
options in Using as
in GNUPro Utilities. There are no V850-specific assembler
command-line options. The V850 syntax is based on the syntax in NEC's V850
User's Manual.
You can use the predefined symbols, r0
through r31, to refer to the V850 registers. V850 also has predefined
symbols for the following general registers.
ep
|
element ptr, synonym for r30
|
gp |
global ptr, synonym for ` r4 ' |
hp
|
synonym for ` r2 handler stack
ptr, '
|
lp
|
link ptr, synonym for ` r31
'
|
sp
|
stack ptr, synonym for ` r3
'
|
tp
|
text ptr, synonym for ` r5
'
|
zero
|
zero register, synonym for ` r0
'
|
Addressing
modes for V850
The assembler understands the following
addressing modes for the V850. The symbol, Rn, in the following
examples refers to any of the specifically numbered registers or register
pairs, but not the control registers (where n signifies
the actual number to specify; see the V850 User's Manual
for actual specifications).
<expr>
Immediate data (angle brackets are not part of the syntax).
disp[Rn]
Register indirect with displacement.
cccc
Condition code (c, e, ge,
gt, h, l, le, lt, n,
nc, ne, nh, nl, ns, nv,
nz, p, s, sa, t, v,
or z).
Floating
point values for V850
Although the V850 has no hardware floating
point, the assembler supports software floating point. The .float
and .double directives generate IEEE-format floating-point values
for compatibility with other development tools.
For detailed information on the V850 machine
instruction set, see V850 User's Manual. The assembler implements
all the standard V850 opcodes.
Assembler
error messages for V850
The following messages output as assembler
error messages.
Error: bad instruction
The instruction is misspelled or there is a syntax error
somewhere.
Error: expression too complex
Error: unresolved expression
that must be resolved
The instruction contains an expression that is too complex;
no relocation exists to handle it.
Linker
information for V850
For a list of available generic linker
options, see Linker scripts
in Using ld in
GNUPro Utilities. In addition, the following V850-specific
command-line option is supported:
--defsym _stack=0xnnnn
Specify the initial value for the stack pointer. This
assumes the application loads the stack pointer with the value of _stack
in the start up code.
See also linker
script for the V850 processor and Producing
S-records for V850.
The initial value for the stack pointer is defined in
the linker script with the PROVIDE linker command. This allows
the user to specify a new value on the command line with the standard linker
option, --defsym.
The GNU linker uses a linker script to
determine how to process each section in an object file, and how to lay
out the executable. The linker script is a declarative program consisting
of a number of directives. For instance, the ENTRY() directive
specifies the symbol in the executable that will be the executable's entry
point. Since linker scripts can be complicated to write, the linker includes
one built-in script that defines the default linking process.
For the V850 tools, the following example shows the default
script for the V850.
Although this script is somewhat lengthy, it is a generic
script that will support all ELF situations. In practice, generation of
sections like .rela.dtors are unlikely when compiling using embedded
ELF tools.
OUTPUT_FORMAT("elf32-v850", "elf32-v850", "elf32-v850")
OUTPUT_ARCH(v850)
ENTRY(_start)
SEARCH_DIR(<installation directory path>);
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0x200000;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.rel.text : { *(.rel.text) }
.rela.text : { *(.rela.text) }
.rel.data : { *(.rel.data) }
.rela.data : { *(.rela.data) }
.rel.rodata : { *(.rel.rodata) }
.rela.rodata : { *(.rela.rodata) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.bss : { *(.rel.bss) }
.rela.bss : { *(.rela.bss) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init : { *(.init) } =0
.plt : { *(.plt) }
.text :
{
*(.text)
/* .gnu.warning sections are handled specially by
elf32.em. */
*(.gnu.warning)
*(.gnu.linkonce.t*)
} =0
_etext = .;
PROVIDE (etext = .);
.fini : { *(.fini) } =0
.rodata : { *(.rodata) *(.gnu.linkonce.r*) }
.rodata1 : { *(.rodata1) }
/* Adjust the address for the data segment. We want to
adjust up to the same address within the page on the
next page up. */
. = ALIGN(32) + (ALIGN(8) & (32 - 1));
.data :
{
*(.data)
*(.gnu.linkonce.d*)
CONSTRUCTORS
}
.data1 : { *(.data1) }
.ctors : { *(.ctors) }
.dtors : { *(.dtors) }
.got : { *(.got.plt) *(.got) }
.dynamic : { *(.dynamic) }
/* We want the small data sections together, so
single-instruction offsets can access them all, and
initialized data all before uninitialized, so we can
shorten the on-disk segment size. */
.sdata : { *(.sdata) }
_edata = .;
PROVIDE (edata = .);
__bss_start = .;
.sbss : { *(.sbss) *(.scommon) }
.bss : { *(.dynbss) *(.bss) *(COMMON) }
_end = . ;
PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the .debug DWARF section are relative to the
beginning of the section so we begin .debug at 0. It's
not clear yet what needs to happen for the others. */
.debug 0 : { *(.debug) }
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
.debug_sfnames 0 : { *(.debug_sfnames) }
.line 0 : { *(.line) }
PROVIDE (_stack = 0x3ffffc);
}
Producing
S-records for V850
The following command reads the contents
of hello.x, converts the code and data into S-records, and puts
the result into hello.srec.
v850-elf-objcopy -O srec hello.x hello.srec
Here are the first few lines of hello.srec:
S00D000068656C6C6F2E7372656303
S31A00100000000220A6FF0000A880AEFFFF401E2000231E0000403B
S31A00100015F610003EF6A86E402611002426A8EE40361000263637
S31A0010002AA86E403E1000273EE06EE7319105460700000636011C
S31A0010003F00E731B1FD80FFA200031EF4FF0032003A004280FF6E
There are no V850-specific debugger command-line
options.
For all available debugger options, see
Debugging with GDB
in GNUPro Debugging Tools.
GDB's built-in software simulation of the V850 processor
allows the debugging of programs compiled for the V850 without requiring
any access to actual hardware. Activate this mode in GDB by the command,
target sim. Then load code into the simulator by the command,
load, and debug it in the normal fashion.
The Target
Selection window for the GNUPro visual
debugger, Cygnus Insight, has additional functionality. Accessible
from Insight's Source Window,
V850 users developing with ICE select a target by entering the name of
the ICE target into the Target Selection
window's dialog box.
Stand-alone
simulator issues for V850
The simulator supports general registers,
r0 through r31, PC (program counter, low 24
bits only), and PSW (low 5 bits only). It does not support any
of the additional system registers or memory mapped registers.
Registers are all uninitialized at startup.
There are no V850-specific stand-alone
simulator command-line options.