| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Although programming languages generally have common aspects, they are
rarely expressed in the same manner. For instance, in ANSI C,
dereferencing a pointer p is accomplished by *p, but in
Modula-2, it is accomplished by p^. Values can also be
represented (and displayed) differently. Hex numbers in C appear as
`0x1ae', while in Modula-2 they appear as `1AEH'.
Language-specific information is built into GDB for some languages, allowing you to express operations like the above in your program's native language, and allowing GDB to output values in a manner consistent with the syntax of your program's native language. The language you use to build expressions is called the working language.
9.1 Switching between source languages 9.2 Displaying the language 9.3 Type and range checking Type and range checks 9.4 Supported languages
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are two ways to control the working language--either have GDB
set it automatically, or select it manually yourself. You can use the
set language command for either purpose. On startup, GDB
defaults to setting the language automatically. The working language is
used to determine how expressions you type are interpreted, how values
are printed, etc.
In addition to the working language, every source file that
GDB knows about has its own working language. For some object
file formats, the compiler might indicate which language a particular
source file is in. However, most of the time GDB infers the
language from the name of the file. The language of a source file
controls whether C++ names are demangled--this way backtrace can
show each frame appropriately for its own language. There is no way to
set the language of a source file from within GDB, but you can
set the language associated with a filename extension. See section Displaying the language.
This is most commonly a problem when you use a program, such
as cfront or f2c, that generates C but is written in
another language. In that case, make the
program use #line directives in its C output; that way
GDB will know the correct language of the source code of the original
program, and will display that source code, not the generated C code.
9.1.1 List of filename extensions and languages Filename extensions and languages. 9.1.2 Setting the working language Setting the working language manually 9.1.3 Having GDB infer the source language
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If a source file name ends in one of the following extensions, then GDB infers that its language is the one indicated.
In addition, you may set the language associated with a filename extension. See section Displaying the language.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you allow GDB to set the language automatically, expressions are interpreted the same way in your debugging session and your program.
If you wish, you may set the language manually. To do this, issue the
command `set language lang', where lang is the name of
a language, such as
c or modula-2.
For a list of the supported languages, type `set language'.
Setting the language manually prevents GDB from updating the working language automatically. This can lead to confusion if you try to debug a program when the working language is not the same as the source language, when an expression is acceptable to both languages--but means different things. For instance, if the current source file were written in C, and GDB was parsing Modula-2, a command such as:
print a = b + c |
might not have the effect you intended. In C, this means to add
b and c and place the result in a. The result
printed would be the value of a. In Modula-2, this means to compare
a to the result of b+c, yielding a BOOLEAN value.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To have GDB set the working language automatically, use `set language local' or `set language auto'. GDB then infers the working language. That is, when your program stops in a frame (usually by encountering a breakpoint), GDB sets the working language to the language recorded for the function in that frame. If the language for a frame is unknown (that is, if the function or block corresponding to the frame was defined in a source file that does not have a recognized extension), the current working language is not changed, and GDB issues a warning.
This may not seem necessary for most programs, which are written entirely in one source language. However, program modules and libraries written in one source language can be used by a main program written in a different source language. Using `set language auto' in this case frees you from having to set the working language manually.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following commands help you find out which language is the working language, and also what language source files were written in.
show language
print to
build and compute expressions that may involve variables in your program.
info frame
info source
In unusual circumstances, you may have source files with extensions not in the standard list. You can then set the extension associated with a language explicitly:
set extension-language .ext language
info extensions
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Warning: In this release, the GDB commands for type and range checking are included, but they do not yet have any effect. This section documents the intended facilities.
Some languages are designed to guard you against making seemingly common errors through a series of compile- and run-time checks. These include checking the type of arguments to functions and operators, and making sure mathematical overflows are caught at run time. Checks such as these help to ensure a program's correctness once it has been compiled by eliminating type mismatches, and providing active checks for range errors when your program is running.
GDB can check for conditions like the above if you wish.
Although GDB does not check the statements in your program, it
can check expressions entered directly into GDB for evaluation via
the print command, for example. As with the working language,
GDB can also decide whether or not to check automatically based on
your program's source language. See section Supported languages,
for the default settings of supported languages.
9.3.1 An overview of type checking 9.3.2 An overview of range checking
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some languages, such as Modula-2, are strongly typed, meaning that the arguments to operators and functions have to be of the correct type, otherwise an error occurs. These checks prevent type mismatch errors from ever causing any run-time problems. For example,
1 + 2 => 3 but error--> 1 + 2.3 |
The second example fails because the CARDINAL 1 is not
type-compatible with the REAL 2.3.
For the expressions you use in GDB commands, you can tell the GDB type checker to skip checking; to treat any mismatches as errors and abandon the expression; or to only issue warnings when type mismatches occur, but evaluate the expression anyway. When you choose the last of these, GDB evaluates expressions like the second example above, but also issues a warning.
Even if you turn type checking off, there may be other reasons
related to type that prevent GDB from evaluating an expression.
For instance, GDB does not know how to add an int and
a struct foo. These particular type errors have nothing to do
with the language in use, and usually arise from expressions, such as
the one described above, which make little sense to evaluate anyway.
Each language defines to what degree it is strict about type. For instance, both Modula-2 and C require the arguments to arithmetical operators to be numbers. In C, enumerated types and pointers can be represented as numbers, so that they are valid arguments to mathematical operators. See section Supported languages, for further details on specific languages.
GDB provides some additional commands for controlling the type checker:
set check type auto
set check type on
set check type off
set check type warn
show type
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In some languages (such as Modula-2), it is an error to exceed the bounds of a type; this is enforced with run-time checks. Such range checking is meant to ensure program correctness by making sure computations do not overflow, or indices on an array element access do not exceed the bounds of the array.
For expressions you use in GDB commands, you can tell GDB to treat range errors in one of three ways: ignore them, always treat them as errors and abandon the expression, or issue warnings but evaluate the expression anyway.
A range error can result from numerical overflow, from exceeding an array index bound, or when you type a constant that is not a member of any type. Some languages, however, do not treat overflows as an error. In many implementations of C, mathematical overflow causes the result to "wrap around" to lower values--for example, if m is the largest integer value, and s is the smallest, then
m + 1 => s |
This, too, is specific to individual languages, and in some cases specific to individual compilers or machines. See section Supported languages, for further details on specific languages.
GDB provides some additional commands for controlling the range checker:
set check range auto
set check range on
set check range off
set check range warn
show range
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB supports C, C++, Fortran, Java, Chill, assembly, and Modula-2.
Some GDB features may be used in expressions regardless of the
language you use: the GDB @ and :: operators,
and the `{type}addr' construct (see section Expressions) can be used with the constructs of any supported
language.
The following sections detail to what degree each source language is supported by GDB. These sections are not meant to be language tutorials or references, but serve only as a reference guide to what the GDB expression parser accepts, and what input and output formats should look like for different languages. There are many good books written on each of these languages; please look to these for a language reference or tutorial.
9.4.1 C and C++ 9.4.2 Modula-2 9.4.3 Chill
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Since C and C++ are so closely related, many features of GDB apply to both languages. Whenever this is the case, we discuss those languages together.
The C++ debugging facilities are jointly implemented by the C++
compiler and GDB. Therefore, to debug your C++ code
effectively, you must compile your C++ programs with a supported
C++ compiler, such as GNU g++, or the HP ANSI C++
compiler (aCC).
For best results when using GNU C++, use the stabs debugging
format. You can select that format explicitly with the g++
command-line options `-gstabs' or `-gstabs+'. See
section `Options for Debugging Your Program or GNU CC' in Using GNU CC, for more information.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Operators must be defined on values of specific types. For instance,
+ is defined on numbers, but not on structures. Operators are
often defined on groups of types.
For the purposes of C and C++, the following definitions hold:
int with any of its storage-class
specifiers; char; enum; and, for C++, bool.
float, double, and
long double (if supported by the target platform).
(type *).
The following operators are supported. They are listed here in order of increasing precedence:
,
=
op=
a op= b,
and translated to a = a op b.
op= and = have the same precedence.
op is any one of the operators |, ^, &,
<<, >>, +, -, *, /, %.
?:
a ? b : c can be thought
of as: if a then b else c. a should be of an
integral type.
||
&&
|
^
&
==, !=
<, >, <=, >=
<<, >>
@
+, -
*, /, %
++, --
*
++.
&
++.
For debugging C++, GDB implements a use of `&' beyond what is allowed in the C++ language itself: you can use `&(&ref)' (or, if you prefer, simply `&&ref') to examine the address where a C++ reference variable (declared with `&ref') is stored.
-
++.
!
++.
~
++.
., ->
struct and union data.
.*, ->*
[]
a[i] is defined as
*(a+i). Same precedence as ->.
()
->.
::
struct, union,
and class types.
::
::,
above.
If an operator is redefined in the user code, GDB usually attempts to invoke the redefined version instead of using the operator's predefined meaning.
9.4.1.2 C and C++ constants
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB allows you to express the constants of C and C++ in the following ways:
long value.
float (as opposed to the default double) type; or with
a letter `l' or `L', which specifies a long double
constant.
'), or a number--the ordinal value of the corresponding character
(usually its ASCII value). Within quotes, the single character may
be represented by a letter or by escape sequences, which are of
the form `\nnn', where nnn is the octal representation
of the character's ordinal value; or of the form `\x', where
`x' is a predefined special character--for example,
`\n' for newline.
"). Any valid character constant (as described
above) may appear. Double quotes within the string must be preceded by
a backslash, so for instance `"a\"b'c"' is a string of five
characters.
9.4.1.3 C++ expressions 9.4.1.4 C and C++ defaults 9.4.1.5 C and C++ type and range checks
9.4.1.6 GDB and C
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB expression handling can interpret most C++ expressions.
Warning: GDB can only debug C++ code if you use the proper compiler. Typically, C++ debugging depends on the use of additional debugging information in the symbol table, and thus requires special support. In particular, if your compiler generates a.out, MIPS ECOFF, RS/6000 XCOFF, or ELF with stabs extensions to the symbol table, these facilities are all available. (With GNU CC, you can use the `-gstabs' option to request stabs debugging extensions explicitly.) Where the object code format is standard COFF or DWARF in ELF, on the other hand, most of the C++ support in GDB does not work.
count = aml->GetOriginal(x, y) |
this following the same rules as C++.
It does perform integral conversions and promotions, floating-point promotions, arithmetic conversions, pointer conversions, conversions of class objects to base classes, and standard conversions such as those of functions or arrays to pointers; it requires an exact match on the number of function arguments.
Overload resolution is always performed, unless you have specified
set overload-resolution off. See section GDB features for C++.
You must specify set overload-resolution off in order to use an
explicit function signature to call an overloaded function, as in
p 'foo(char,int)'('x', 13)
|
The GDB command-completion facility can simplify this; see Command completion.
In the parameter list shown when GDB displays a frame, the values of reference variables are not displayed (unlike other variables); this avoids clutter, since references are often used for large structures. The address of a reference variable is always shown, unless you have specified `set print address off'.
::---your
expressions can use it just as expressions in your program do. Since
one scope may be defined in another, you can use :: repeatedly if
necessary, for example in an expression like
`scope1::scope2::name'. GDB also allows
resolving name scope by reference to source files, in both C and C++
debugging (see section Program variables).
In addition, when used with HP's C++ compiler, GDB supports calling virtual functions correctly, printing out virtual bases of objects, calling functions in a base subobject, casting objects, and invoking user-defined operators.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you allow GDB to set type and range checking automatically, they
both default to off whenever the working language changes to
C or C++. This happens regardless of whether you or GDB
selects the working language.
If you allow GDB to set the language automatically, it recognizes source files whose names end with `.c', `.C', or `.cc', etc, and when GDB enters code compiled from one of these files, it sets the working language to C or C++. See section Having GDB infer the source language, for further details.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
By default, when GDB parses C or C++ expressions, type checking is not used. However, if you turn type checking on, GDB considers two variables type equivalent if:
typedef.
Range checking, if turned on, is done on mathematical operations. Array indices are not checked, since they are often used to index a pointer that is not itself an array.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The set print union and show print union commands apply to
the union type. When set to `on', any union that is
inside a struct or class is also printed. Otherwise, it
appears as `{...}'.
The @ operator aids in the debugging of dynamic arrays, formed
with pointers and a memory allocation function. See section Expressions.
9.4.1.7 GDB features for C++
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GDB commands are particularly useful with C++, and some are designed specifically for use with C++. Here is a summary:
breakpoint menus
rbreak regex
catch throw
catch catch
ptype typename
set print demangle
show print demangle
set print asm-demangle
show print asm-demangle
set print object
show print object
set print vtbl
show print vtbl
vtbl commands do not work on programs compiled with the HP
ANSI C++ compiler (aCC).)
set overload-resolution on
set overload-resolution off
Overloaded symbol names
symbol(types) rather than just symbol. You can
also use the GDB command-line word completion facilities to list the
available choices, or to finish the type list for you.
See section Command completion, for details on how to do this.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The extensions made to GDB to support Modula-2 only support output from the GNU Modula-2 compiler (which is currently being developed). Other Modula-2 compilers are not currently supported, and attempting to debug executables produced by them is most likely to give an error as GDB reads in the executable's symbol table.
9.4.2.1 Operators Built-in operators 9.4.2.2 Built-in functions and procedures 9.4.2.3 Constants Modula-2 constants 9.4.2.4 Modula-2 defaults Default settings for Modula-2 9.4.2.5 Deviations from standard Modula-2 9.4.2.6 Modula-2 type and range checks 9.4.2.7 The scope operators ::and.9.4.2.8 GDB and Modula-2
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Operators must be defined on values of specific types. For instance,
+ is defined on numbers, but not on structures. Operators are
often defined on groups of types. For the purposes of Modula-2, the
following definitions hold:
INTEGER, CARDINAL, and
their subranges.
CHAR and its subranges.
REAL.
POINTER TO
type.
SET and BITSET types.
BOOLEAN.
The following operators are supported, and appear in order of increasing precedence:
,
:=
:= value is
value.
<, >
<=, >=
<.
=, <>, #
<. In GDB scripts, only <> is
available for inequality, since # conflicts with the script
comment character.
IN
<.
OR
AND, &
@
+, -
*
/
*.
DIV, MOD
*.
-
INTEGER and REAL data.
^
NOT
^.
.
RECORD field selector. Defined on RECORD data. Same
precedence as ^.
[]
ARRAY data. Same precedence as ^.
()
PROCEDURE objects. Same precedence
as ^.
::, .
Warning: Sets and their operations are not yet supported, so GDB treats the use of the operatorIN, or the use of operators+,-,*,/,=, ,<>,#,<=, and>=on sets as an error.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Modula-2 also makes available several built-in procedures and functions. In describing these, the following metavariables are used:
ARRAY variable.
CHAR constant or variable.
SET OF mtype (where mtype is the type of m).
All Modula-2 built-in procedures also return a result, described below.
ABS(n)
CAP(c)
CHR(i)
DEC(v)
DEC(v,i)
EXCL(m,s)
FLOAT(i)
HIGH(a)
INC(v)
INC(v,i)
INCL(m,s)
MAX(t)
MIN(t)
ODD(i)
ORD(x)
SIZE(x)
TRUNC(r)
VAL(t,i)
Warning: Sets and their operations are not yet supported, so GDB treats the use of proceduresINCLandEXCLas an error.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB allows you to express the constants of Modula-2 in the following ways:
') or double ("). They may
also be expressed by their ordinal value (their ASCII value, usually)
followed by a `C'.
') or double (").
Escape sequences in the style of C are also allowed. See section C and C++ constants, for a brief explanation of escape
sequences.
TRUE and
FALSE.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If type and range checking are set automatically by GDB, they
both default to on whenever the working language changes to
Modula-2. This happens regardless of whether you or GDB
selected the working language.
If you allow GDB to set the language automatically, then entering code compiled from a file whose name ends with `.mod' sets the working language to Modula-2. See section Having GDB set the language automatically, for further details.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A few changes have been made to make Modula-2 programs easier to debug. This is done primarily via loosening its type strictness:
:=) returns the value of its right-hand
argument.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Warning: in this release, GDB does not yet perform type or range checking.
GDB considers two Modula-2 variables type equivalent if:
TYPE
t1 = t2 statement
As long as type checking is enabled, any attempt to combine variables whose types are not equivalent is an error.
Range checking is done on all mathematical operations, assignment, array index bounds, and all built-in functions and procedures.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
:: and .
There are a few subtle differences between the Modula-2 scope operator
(.) and the GDB scope operator (::). The two have
similar syntax:
module . id scope :: id |
where scope is the name of a module or a procedure, module the name of a module, and id is any declared identifier within your program, except another module.
Using the :: operator makes GDB search the scope
specified by scope for the identifier id. If it is not
found in the specified scope, then GDB searches all scopes
enclosing the one specified by scope.
Using the . operator makes GDB search the current scope for
the identifier specified by id that was imported from the
definition module specified by module. With this operator, it is
an error if the identifier id was not imported from definition
module module, or if id is not an identifier in
module.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some GDB commands have little use when debugging Modula-2 programs.
Five subcommands of set print and show print apply
specifically to C and C++: `vtbl', `demangle',
`asm-demangle', `object', and `union'. The first four
apply to C++, and the last to the C union type, which has no direct
analogue in Modula-2.
The @ operator (see section Expressions), while available
with any language, is not useful with Modula-2. Its
intent is to aid the debugging of dynamic arrays, which cannot be
created in Modula-2 as they can in C or C++. However, because an
address can be specified by an integral constant, the construct
`{type}adrexp' is still useful.
In GDB scripts, the Modula-2 inequality operator # is
interpreted as the beginning of a comment. Use <> instead.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The extensions made to GDB to support Chill only support output from the GNU Chill compiler. Other Chill compilers are not currently supported, and attempting to debug executables produced by them is most likely to give an error as GDB reads in the executable's symbol table.
This section covers the Chill related topics and the features of GDB which support these topics.
9.4.3.1 How modes are displayed 9.4.3.2 Locations and their accesses 9.4.3.3 Values and their Operations 9.4.3.4 Chill type and range checks 9.4.3.5 Chill defaults
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Chill Datatype- (Mode) support of GDB is directly related with the functionality of the GNU Chill compiler, and therefore deviates slightly from the standard specification of the Chill language. The provided modes are:
Discrete modes:
BYTE, UBYTE, INT,
UINT, LONG, ULONG,
BOOL,
CHAR,
SET.
(gdb) ptype x type = SET (karli = 10, susi = 20, fritzi = 100) |
|
<lower bound>, <upper bound> can be of any discrete literal
expression (e.g. set element names).
Powerset Mode:
POWERSET followed by
the member mode of the powerset. The member mode can be any discrete mode.
(gdb) ptype x type = POWERSET SET (egon, hugo, otto) |
Reference Modes:
REF
followed by the mode name to which the reference is bound.
PTR.
Procedure mode
type = PROC(<parameter list>)
<return mode> EXCEPTIONS (<exception list>). The <parameter
list> is a list of the parameter modes. <return mode> indicates
the mode of the result of the procedure if any. The exceptionlist lists
all possible exceptions which can be raised by the procedure.
Synchronization Modes:
|
(<event length>) is optional.
|
(<buffer length>) is optional.
Timing Modes:
DURATION
TIME
Real Modes:
REAL and LONG_REAL.
String Modes:
|
VARYING if the String Mode is a varying
mode
|
Array Mode:
ARRAY(<range>)
followed by the element mode (which may in turn be an array mode).
(gdb) ptype x
type = ARRAY (1:42)
ARRAY (1:20)
SET (karli = 10, susi = 20, fritzi = 100)
|
Structure Mode
STRUCT(<field
list>). The <field list> consists of names and modes of fields
of the structure. Variant structures have the keyword CASE <field>
OF <variant fields> ESAC in their field list. Since the current version
of the GNU Chill compiler doesn't implement tag processing (no runtime
checks of variant fields, and therefore no debugging info), the output
always displays all variant fields.
(gdb) ptype str
type = STRUCT (
as x,
bs x,
CASE bs OF
(karli):
cs a
(ott):
ds x
ESAC
)
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A location in Chill is an object which can contain values.
A value of a location is generally accessed by the (declared) name of the location. The output conforms to the specification of values in Chill programs. How values are specified is the topic of the next section, 9.4.3.3 Values and their Operations.
The pseudo-location RESULT (or result) can be used to
display or change the result of a currently-active procedure:
set result := EXPR |
This does the same as the Chill action RESULT EXPR (which
is not available in GDB).
Values of reference mode locations are printed by PTR(<hex
value>) in case of a free reference mode, and by (REF <reference
mode>) (<hex-value>) in case of a bound reference. <hex value>
represents the address where the reference points to. To access the
value of the location referenced by the pointer, use the dereference
operator `->'.
Values of procedure mode locations are displayed by
|
<argument modes> is a list of modes according to the parameter
specification of the procedure and <address> shows the address of
the entry point.
Substructures of string mode-, array mode- or structure mode-values (e.g. array slices, fields of structure locations) are accessed using certain operations which are described in the next section, 9.4.3.3 Values and their Operations.
A location value may be interpreted as having a different mode using the
location conversion. This mode conversion is written as <mode
name>(<location>). The user has to consider that the sizes of the modes
have to be equal otherwise an error occurs. Furthermore, no range
checking of the location against the destination mode is performed, and
therefore the result can be quite confusing.
(gdb) print int (s(3 up 4)) XXX TO be filled in !! XXX |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Values are used to alter locations, to investigate complex structures in more detail or to filter relevant information out of a large amount of data. There are several (mode dependent) operations defined which enable such investigations. These operations are not only applicable to constant values but also to locations, which can become quite useful when debugging complex structures. During parsing the command line (e.g. evaluating an expression) GDB treats location names as the values behind these locations.
This section describes how values have to be specified and which operations are legal to be used with such values.
Literal Values
Tuple Values
<mode name>[<tuple>], where <mode
name> can be omitted if the mode of the tuple is unambiguous. This
unambiguity is derived from the context of a evaluated expression.
<tuple> can be one of the following:
String Element Value
|
<index> is a integer expression. It delivers a character
value which is equivalent to the character indexed by <index> in
the string.
String Slice Value
<string value>(<slice
spec>), where <slice spec> can be either a range of integer
expressions or specified by <start expr> up <size>.
<size> denotes the number of elements which the slice contains.
The delivered value is a string value, which is part of the specified
string.
Array Element Values
<array value>(<expr>) and
delivers a array element value of the mode of the specified array.
Array Slice Values
<array value>(<slice spec>), where
<slice spec> can be either a range specified by expressions or by
<start expr> up <size>. <size> denotes the number of
arrayelements the slice contains. The delivered value is an array value
which is part of the specified array.
Structure Field Values
<structure value>.<field
name>, where <field name> indicates the name of a field specified
in the mode definition of the structure. The mode of the delivered value
corresponds to this mode definition in the structure definition.
Procedure Call Value
Values of duration mode locations are represented by ULONG literals.
Values of time mode locations appear as
|
Zero-adic Operator Value
Expression Values
OR, ORIF, XORAND, ANDIFNOT
=, /=
>, >=<, <=
+, -*, /, MOD, REM
-
//
()
->->loc), or to dereference a reference
location (loc->).
OR, XORANDNOT
>, >=<, <=
IN
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB considers two Chill variables mode equivalent if the sizes of the two modes are equal. This rule applies recursively to more complex datatypes which means that complex modes are treated equivalent if all element modes (which also can be complex modes like structures, arrays, etc.) have the same size.
Range checking is done on all mathematical operations, assignment, array index bounds and all built in procedures.
Strong type checks are forced using the GDB command set
check strong. This enforces strong type and range checks on all
operations where Chill constructs are used (expressions, built in
functions, etc.) in respect to the semantics as defined in the z.200
language specification.
All checks can be disabled by the GDB command set check
off.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If type and range checking are set automatically by GDB, they
both default to on whenever the working language changes to
Chill. This happens regardless of whether you or GDB
selected the working language.
If you allow GDB to set the language automatically, then entering code compiled from a file whose name ends with `.ch' sets the working language to Chill. See section Having GDB set the language automatically, for further details.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |