Debugging with GDB - Using GDB with Different Languages

Go to the first, previous, next, last section, table of contents.

# Using GDB with Different Languages

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.

## Switching between source languages

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.

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.

### List of filename extensions and languages

If a source file name ends in one of the following extensions, then GDB infers that its language is the one indicated.

``.c'`
  C source file
``.C'`
``.cc'`
``.cp'`
``.cpp'`
``.cxx'`
``.c++'`
  C++ source file
``.m'`
  Objective-C source file
``.M'`
  Objective-C++ source file
``.f'`
``.F'`
  Fortran source file
``.ch'`
``.c186'`
``.c286'`
  CHILL source file.
``.mod'`
  Modula-2 source file
``.s'`
``.S'`
  Assembler source file. This actually behaves almost like C, but GDB does not skip over function prologues when stepping.

In addition, you may set the language associated with a filename extension. See section Displaying the language.

### Setting the working language

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.

### Having GDB infer the source language

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.

## Displaying the language

The following commands help you find out which language is the working language, and also what language source files were written in.

`show language`
  Display the current working language. This is the language you can use with commands such as `print` to build and compute expressions that may involve variables in your program.
`info frame`
  Display the source language for this frame. This language becomes the working language if you use an identifier from this frame. See section Information about a frame, to identify the other information listed here.
`info source`
  Display the source language of this source file. See section Examining the Symbol Table, to identify the other information listed here.

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`
  Set source files with extension .ext to be assumed to be in the source language language.
`info extensions`
  List all the filename extensions and the associated languages.

## Type and range checking

> 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.

### An overview of type checking

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 type checking on or off based on the current working language. See section Supported languages, for the default settings for each language.
`set check type on`
`set check type off`
  Set type checking on or off, overriding the default setting for the current working language. Issue a warning if the setting does not match the language default. If any type mismatches occur in evaluating an expression while typechecking is on, GDB prints a message and aborts evaluation of the expression.
`set check type warn`
  Cause the type checker to issue warnings, but to always attempt to evaluate the expression. Evaluating the expression may still be impossible for other reasons. For example, GDB cannot add numbers and structures.
`show type`
  Show the current setting of the type checker, and whether or not GDB is setting it automatically.

### An overview of range checking

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 range checking on or off based on the current working language. See section Supported languages, for the default settings for each language.
`set check range on`
`set check range off`
  Set range checking on or off, overriding the default setting for the current working language. A warning is issued if the setting does not match the language default. If a range error occurs, then a message is printed and evaluation of the expression is aborted.
`set check range warn`
  Output messages when the GDB range checker detects a range error, but attempt to evaluate the expression anyway. Evaluating the expression may still be impossible for other reasons, such as accessing memory that the process does not own (a typical example from many Unix systems).
`show range`
  Show the current setting of the range checker, and whether or not it is being set automatically by GDB.

## Supported languages

GDB supports C, C++, Objective-C, Objective-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.

### C and C++

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.

#### C and C++ operators

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:

- Integral types include `int` with any of its storage-class specifiers; `char`; and `enum`.
- Floating-point types include `float` and `double`.
- Pointer types include all types defined as `(type *)`.
- Scalar types include all of the above.

The following operators are supported. They are listed here in order of increasing precedence:

`,`
  The comma or sequencing operator. Expressions in a comma-separated list are evaluated from left to right, with the result of the entire expression being the last expression evaluated.
`=`
  Assignment. The value of an assignment expression is the value assigned. Defined on scalar types.
`op=`
  Used in an expression of the form `a op= b`, and translated to `a = a op b`. `op=` and `=` have the same precendence. op is any one of the operators `|`, `^`, `&`, `<<`, `>>`, `+`, `-`, `*`, `/`, `%`.
`?:`
  The ternary operator. `a ? b : c` can be thought of as: if a then b else c. a should be of an integral type.
`||`
  Logical OR. Defined on integral types.
`&&`
  Logical AND. Defined on integral types.
`|`
  Bitwise OR. Defined on integral types.
`^`
  Bitwise exclusive-OR. Defined on integral types.
`&`
  Bitwise AND. Defined on integral types.
`==, !=`
  Equality and inequality. Defined on scalar types. The value of these expressions is 0 for false and non-zero for true.
`<, >, <=, >=`
  Less than, greater than, less than or equal, greater than or equal. Defined on scalar types. The value of these expressions is 0 for false and non-zero for true.
`<<, >>`
  left shift, and right shift. Defined on integral types.
`@`
  The GDB "artificial array" operator (see section Expressions).
`+, -`
  Addition and subtraction. Defined on integral types, floating-point types and pointer types.
`*, /, %`
  Multiplication, division, and modulus. Multiplication and division are defined on integral and floating-point types. Modulus is defined on integral types.
`++, --`
  Increment and decrement. When appearing before a variable, the operation is performed before the variable is used in an expression; when appearing after it, the variable's value is used before the operation takes place.
`*`
  Pointer dereferencing. Defined on pointer types. Same precedence as `++`.
`&`
  Address operator. Defined on variables. Same precedence as `++`. 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.
`-`
  Negative. Defined on integral and floating-point types. Same precedence as `++`.
`!`
  Logical negation. Defined on integral types. Same precedence as `++`.
`~`
  Bitwise complement operator. Defined on integral types. Same precedence as `++`.
`., ->`
  Structure member, and pointer-to-structure member. For convenience, GDB regards the two as equivalent, choosing whether to dereference a pointer based on the stored type information. Defined on `struct` and `union` data.
`[]`
  Array indexing. `a[i]` is defined as `*(a+i)`. Same precedence as `->`.
`()`
  Function parameter list. Same precedence as `->`.
`::`
  C++ scope resolution operator. Defined on `struct`, `union`, and `class` types.
`::`
  Doubled colons also represent the GDB scope operator (see section Expressions). Same precedence as `::`, above.

#### C and C++ constants

GDB allows you to express the constants of C and C++ in the following ways:

- Integer constants are a sequence of digits. Octal constants are specified by a leading ``0'` (i.e. zero), and hexadecimal constants by a leading ``0x'` or ``0X'`. Constants may also end with a letter ``l'`, specifying that the constant should be treated as a `long` value.
- Floating point constants are a sequence of digits, followed by a decimal point, followed by a sequence of digits, and optionally followed by an exponent. An exponent is of the form: ``e[[+]|-]nnn'`, where nnn is another sequence of digits. The ``+'` is optional for positive exponents.
- Enumerated constants consist of enumerated identifiers, or their integral equivalents.
- Character constants are a single character surrounded by single quotes (`'`), 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.
- String constants are a sequence of character constants surrounded by double quotes (`"`).
- Pointer constants are an integral value. You can also write pointers to constants using the C operator ``&'`.
- Array constants are comma-separated lists surrounded by braces ``{'` and ``}'`; for example, ``{1,2,3}'` is a three-element array of integers, ``{{1,2}, {3,4}, {5,6}}'` is a three-by-two array, and ``{&"hi", &"there", &"fred"}'` is a three-element array of pointers.

#### C++ expressions

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.

1. Member function calls are allowed; you can use expressions like

       count = aml->GetOriginal(x, y)

2. While a member function is active (in the selected stack frame), your expressions have the same namespace available as the member function; that is, GDB allows implicit references to the class instance pointer `this` following the same rules as C++.
3. You can call overloaded functions; GDB resolves the function call to the right definition, with one restriction--you must use arguments of the type required by the function that you want to call. GDB does not perform conversions requiring constructors or user-defined type operators.
4. GDB understands variables declared as C++ references; you can use them in expressions just as you do in C++ source--they are automatically dereferenced. 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'`.
5. GDB supports the C++ name resolution operator `::`---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).

#### C and C++ defaults

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.

#### C and C++ type and range checks

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:

- The two variables are structured and have the same structure, union, or enumerated tag.
- The two variables have the same type name, or types that have been declared equivalent through `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.

#### GDB and C

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.

#### GDB features for C++

Some GDB commands are particularly useful with C++, and some are designed specifically for use with C++. Here is a summary:

`breakpoint menus`
  When you want a breakpoint in a function whose name is overloaded, GDB breakpoint menus help you specify which function definition you want. See section Breakpoint menus.
`rbreak regex`
  Setting breakpoints using regular expressions is helpful for setting breakpoints on overloaded functions that are not members of any special classes. See section Setting breakpoints.
`catch throw`
`catch catch`
  Debug C++ exception handling using these commands. See section Setting catchpoints.
`ptype typename`
  Print inheritance relationships as well as other information for type typename. See section Examining the Symbol Table.
`set print demangle`
`show print demangle`
`set print asm-demangle`
`show print asm-demangle`
  Control whether C++ symbols display in their source form, both when displaying code as C++ source and when displaying disassemblies. See section Print settings.
`set print object`
`show print object`
  Choose whether to print derived (actual) or declared types of objects. See section Print settings.
`set print vtbl`
`show print vtbl`
  Control the format for printing virtual function tables. See section Print settings.
`Overloaded symbol names`
  You can specify a particular definition of an overloaded symbol, using the same notation that is used to declare such symbols in C++: type `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.

### Modula-2

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.

#### Operators

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:

- Integral types consist of `INTEGER`, `CARDINAL`, and their subranges.
- Character types consist of `CHAR` and its subranges.
- Floating-point types consist of `REAL`.
- Pointer types consist of anything declared as `POINTER TO type`.
- Scalar types consist of all of the above.
- Set types consist of `SET` and `BITSET` types.
- Boolean types consist of `BOOLEAN`.

The following operators are supported, and appear in order of increasing precedence:

`,`
  Function argument or array index separator.
`:=`
  Assignment. The value of var `:=` value is value.
`<, >`
  Less than, greater than on integral, floating-point, or enumerated types.
`<=, >=`
  Less than, greater than, less than or equal to, greater than or equal to on integral, floating-point and enumerated types, or set inclusion on set types. Same precedence as `<`.
`=, <>, #`
  Equality and two ways of expressing inequality, valid on scalar types. Same precedence as `<`. In GDB scripts, only `<>` is available for inequality, since `#` conflicts with the script comment character.
`IN`
  Set membership. Defined on set types and the types of their members. Same precedence as `<`.
`OR`
  Boolean disjunction. Defined on boolean types.
`AND, &`
  Boolean conjuction. Defined on boolean types.
`@`
  The GDB "artificial array" operator (see section Expressions).
`+, -`
  Addition and subtraction on integral and floating-point types, or union and difference on set types.
`*`
  Multiplication on integral and floating-point types, or set intersection on set types.
`/`
  Division on floating-point types, or symmetric set difference on set types. Same precedence as `*`.
`DIV, MOD`
  Integer division and remainder. Defined on integral types. Same precedence as `*`.
`-`
  Negative. Defined on `INTEGER` and `REAL` data.
`^`
  Pointer dereferencing. Defined on pointer types.
`NOT`
  Boolean negation. Defined on boolean types. Same precedence as `^`.
`.`
  `RECORD` field selector. Defined on `RECORD` data. Same precedence as `^`.
`[]`
  Array indexing. Defined on `ARRAY` data. Same precedence as `^`.
`()`
  Procedure argument list. Defined on `PROCEDURE` objects. Same precedence as `^`.
`::, .`
  GDB and Modula-2 scope operators.

> Warning: Sets and their operations are not yet supported, so GDB treats the use of the operator `IN`, or the use of operators `+`, `-`, `*`, `/`, `=`, , `<>`, `#`, `<=`, and `>=` on sets as an error.

#### Built-in functions and procedures

Modula-2 also makes available several built-in procedures and functions. In describing these, the following metavariables are used:

a
  represents an `ARRAY` variable.
c
  represents a `CHAR` constant or variable.
i
  represents a variable or constant of integral type.
m
  represents an identifier that belongs to a set. Generally used in the same function with the metavariable s. The type of s should be `SET OF mtype` (where mtype is the type of m).
n
  represents a variable or constant of integral or floating-point type.
r
  represents a variable or constant of floating-point type.
t
  represents a type.
v
  represents a variable.
x
  represents a variable or constant of one of many types. See the explanation of the function for details.

All Modula-2 built-in procedures also return a result, described below.

`ABS(n)`
  Returns the absolute value of n.
`CAP(c)`
  If c is a lower case letter, it returns its upper case equivalent, otherwise it returns its argument
`CHR(i)`
  Returns the character whose ordinal value is i.
`DEC(v)`
  Decrements the value in the variable v. Returns the new value.
`DEC(v,i)`
  Decrements the value in the variable v by i. Returns the new value.
`EXCL(m,s)`
  Removes the element m from the set s. Returns the new set.
`FLOAT(i)`
  Returns the floating point equivalent of the integer i.
`HIGH(a)`
  Returns the index of the last member of a.
`INC(v)`
  Increments the value in the variable v. Returns the new value.
`INC(v,i)`
  Increments the value in the variable v by i. Returns the new value.
`INCL(m,s)`
  Adds the element m to the set s if it is not already there. Returns the new set.
`MAX(t)`
  Returns the maximum value of the type t.
`MIN(t)`
  Returns the minimum value of the type t.
`ODD(i)`
  Returns boolean TRUE if i is an odd number.
`ORD(x)`
  Returns the ordinal value of its argument. For example, the ordinal value of a character is its ASCII value (on machines supporting the ASCII character set). x must be of an ordered type, which include integral, character and enumerated types.
`SIZE(x)`
  Returns the size of its argument. x can be a variable or a type.
`TRUNC(r)`
  Returns the integral part of r.
`VAL(t,i)`
  Returns the member of the type t whose ordinal value is i.

> Warning: Sets and their operations are not yet supported, so GDB treats the use of procedures `INCL` and `EXCL` as an error.

#### Constants

GDB allows you to express the constants of Modula-2 in the following ways:

- Integer constants are simply a sequence of digits. When used in an expression, a constant is interpreted to be type-compatible with the rest of the expression. Hexadecimal integers are specified by a trailing ``H'`, and octal integers by a trailing ``B'`.
- Floating point constants appear as a sequence of digits, followed by a decimal point and another sequence of digits. An optional exponent can then be specified, in the form ``E[+|-]nnn'`, where ``[+|-]nnn'` is the desired exponent. All of the digits of the floating point constant must be valid decimal (base 10) digits.
- Character constants consist of a single character enclosed by a pair of like quotes, either single (`'`) or double (`"`). They may also be expressed by their ordinal value (their ASCII value, usually) followed by a ``C'`.
- String constants consist of a sequence of characters enclosed by a pair of like quotes, either single (`'`) 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.
- Enumerated constants consist of an enumerated identifier.
- Boolean constants consist of the identifiers `TRUE` and `FALSE`.
- Pointer constants consist of integral values only.
- Set constants are not yet supported.

#### Modula-2 defaults

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 infer the source language, for further details.

#### Deviations from standard Modula-2

A few changes have been made to make Modula-2 programs easier to debug. This is done primarily via loosening its type strictness:

- Unlike in standard Modula-2, pointer constants can be formed by integers. This allows you to modify pointer variables during debugging. (In standard Modula-2, the actual address contained in a pointer variable is hidden from you; it can only be modified through direct assignment to another pointer variable or expression that returned a pointer.)
- C escape sequences can be used in strings and characters to represent non-printable characters. GDB prints out strings with these escape sequences embedded. Single non-printable characters are printed using the ``CHR(nnn)'` format.
- The assignment operator (`:=`) returns the value of its right-hand argument.
- All built-in procedures both modify and return their argument.

#### Modula-2 type and range checks

> Warning: in this release, GDB does not yet perform type or range checking.

GDB considers two Modula-2 variables type equivalent if:

- They are of types that have been declared equivalent via a `TYPE t1 = t2` statement
- They have been declared on the same line. (Note: This is true of the GNU Modula-2 compiler, but it may not be true of other compilers.)

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.

#### The scope operators `::` 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.

#### GDB and Modula-2

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 while using 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. (see section Expressions)

In GDB scripts, the Modula-2 inequality operator `#` is interpreted as the beginning of a comment. Use `<>` instead.

### Chill

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 following Chill related topics and the features of GDB which support these topics.

#### How modes are displayed

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:`
  - Integer Modes which are predefined by `BYTE, UBYTE, INT, UINT, LONG, ULONG`,
  - Boolean Mode which is predefined by `BOOL`,
  - Character Mode which is predefined by `CHAR`,
  - Set Mode which is displayed by the keyword `SET`.

        (gdb) ptype x
        type = SET (karli = 10, susi = 20, fritzi = 100)

    If the type is an unnumbered set the set element values are omitted.
  - Range Mode which is displayed by `type = <basemode> (<lower bound> : <upper bound>)`, where `<lower bound>, <upper bound>` can be of any discrete literal expression (e.g. set element names).
`Powerset Mode:`
  A Powerset Mode is displayed by the keyword `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:`
  - Bound Reference Mode which is diplayed by the keyword `REF` followed by the mode name to which the reference is bound.
  - Free Reference Mode which is displayed by the keyword `PTR`.
`Procedure mode`
  The procedure mode is displayed by `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 Mode which is displayed by `EVENT (<event length>)`, where `(<event length>)` is optional.
  - Buffer Mode which is displayed by `BUFFER (<buffer length>) <buffer element mode>`, where `(<buffer length>)` is optional.
`Timing Modes:`
  - Duration Mode which is predefined by `DURATION`
  - Absolute Time Mode which is predefined by `TIME`
`Real Modes:`
  Real Modes are predefined with `REAL` and `LONG_REAL`.
`String Modes:`
  - Character String Mode which is displayed by `CHARS(<string length>)`, followed by the keyword `VARYING` if the String Mode is a varying mode
  - Bit String Mode which is displayed by `BOOLS(<string length>)`.
`Array Mode:`
  The Array Mode is displayed by the keyword `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`
  The Structure mode is displayed by the keyword `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
      )

#### Locations and their accesses

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, and which operations are valid is the topic of the next section.

The pseudo-location `RESULT` (or `result`) can be used to display or change the result of a currently-active procedure:

    set result := EXPR

- 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 `{ PROC (<argument modes> ) <return mode> } <address> <name of procedure location>`. `<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 descibed in the next chapter.

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 message occurs. Further 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

#### Values and their Operations

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 subchapters describes how values have to be specified and which operations are legal to be used with such values.

`Literal Values`
  Literal values are specified in the same manner as in GNU Chill programs. For detailed specification refer to the GNU Chill implementation Manual chapter 1.5.
`Tuple Values`
  A tuple is specified by `<mode name>[<tuple>]`, where `<mode name>` can be omitted if the mode of the tuple is unambigous. This unambiguity is derived from the context of a evaluated expression. `<tuple>` can be one of the following:
  - Powerset Tuple
  - Array Tuple
  - Structure Tuple Powerset tuples, array tuples and structure tuples are specified in the same manner as in Chill programs refer z200/88 chpt 5.2.5.
`String Element Value`
  A string element value is specified by `<string value>(<index>)`, where `<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`
  A string slice value is specified by `<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`
  An array element value is specified by `<array value>(<expr>)` and delivers a array element value of the mode of the specified array.
`Array Slice Values`
  An array slice is specified by `<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`
  A structure field value is derived by `<structure value>.<field name>`, where `<field name>` indcates 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`
  The procedure call value is derived from the return value of the procedure(3). Values of duration mode locations are represented by ULONG literals. Values of time mode locations are represented by TIME(<secs>:<nsecs>).
`Zero-adic Operator Value`
  The zero-adic operator value is derived from the instance value for the current active process.
`Expression Values`
  The value delivered by an expression is the result of the evaluation of the specified expression. If there are error conditions (mode incompatibility, etc.) the evaluation of expressions is aborted with a corresponding error message. Expressions may be paranthesised which causes the evaluation of this expression before any other expression which uses the result of the paranthesised expression. The following operators are supported by GDB:
  ``OR, ORIF, XOR``
  ``AND, ANDIF``
  ``NOT``
    Logical operators defined over operands of boolean mode.
  ``=, /=``
    Equality and inequality operators defined over all modes.
  ``>, >=``
  ``<, <=``
    Relational operators defined over predefined modes.
  ``+, -``
  ``*, /, MOD, REM``
    Arithmetic operators defined over predefined modes.
  ``-``
    Change sign operator.
  ``//``
    String concatenation operator.
  ``()``
    String repetition operator.
  ``->``
    Referenced location operator which can be used either to take the address of a location (`->loc`), or to dereference a reference location (`loc->`).
  ``OR, XOR``
  ``AND``
  ``NOT``
    Powerset and bitstring operators.
  ``>, >=``
  ``<, <=``
    Powerset inclusion operators.
  ``IN``
    Membership operator.

#### Chill type and range checks

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 eqivalent 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`.

#### Chill defaults

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 infer the source language, for further details.

### Objective-C/C++

This section provides information about some commands and command options that are useful for debugging Objective-C and Objective-C++ code.

#### Method Names in Commands

The following commands have been extended to accept Objective-C method names as line specifications:

- `clear`
- `break`
- `info line`
- `jump`
- `list`

For example, to set a breakpoint at the `create` instance method of class `Fruit` in the program currently being debugged, enter:

    break -[Fruit create]

To list ten program lines around the `initialize` class method, enter:

    list +[NSText initialize]

In the current version of GDB, the plus or minus sign is required. In future versions of GDB, the plus or minus sign will be optional, but you can use it to narrow the search. It is also possible to specify just a method name:

    break create

You must specify the complete method name, including any colons. If your program's source files contain more than one `create` method, you'll be presented with a numbered list of classes that implement that method. Indicate your choice by number, or type ``0'` to exit if none apply.

As another example, to clear a breakpoint established at the `makeKeyAndOrderFront:` method of the `NSWindow` class, enter:

    clear -[NSWindow makeKeyAndOrderFront:]

#### Command Descriptions

This section describes commands and options that are useful in debugging Objective-C/C++ code. Some of these are commands added specifically to support Objective-C/C++; others are previously existing GDB commands that have been extended to support Objective-C/C++.

`info classes`
  @xref{info classes}
`info selectors`
  @xref{info selectors}

#### Objective-C/C++ Expressions

### PostScript

This section describes commands that are useful when debugging PostScript source files.

These commands are not built directly into GDB; rather, the OpenStep environment defines them in the system-level GDB configuration file (). This file is read when you start running GDB (the contents of this file are shown later in this chapter).

`showps, shownops`
  The `showps` and `shownops` commands turn on and off (respectively) the display of PostScript code being sent from your application to the Window Server. Your application must be running before you can issue either of these commands.
`flushps`
  The `flushps` command sends pending PostScript code to the Window Server. This command lets you flush the application's output buffer, causing any PostScript code waiting there to be interrupted immediately. Your application must be running before you can issue this command.
`traceevents, tracenoevents`
  The `traceevents` and `tracenoevents` commands turn on (respecively) tracing of PostScript events. When PostScript event tracing is enabled, all events received from the Window Server are logged to the standard error output stream.
`waitps`
  The `waitps` command waits until the current Display Postscript Context is ready to receive more input.

Go to the first, previous, next, last section, table of contents.