Contents

# KDbg's Type Table

KDbg can display a short description of structured types, so that it is not necessary to expand the variable in the local variables window or watched expressions window. The information which member variable is displayed is stored in type tables. There is generally one type table per shared library.

KDbg's default type tables are located under `$prefix/share/apps/kdbg/types`. User defined type tables can be placed in `${KDEHOME}/share/apps/kdbg/types`, where `${KDEHOME}` is `~/.kde` if it is not a defined environment variable. The file names end with `.kdbgtt`. Example: The type table for `libqt.so` is named `qt.kdbgtt`. User defined type tables override the type tables provided by the system.

A type table file obeys the regular KDE configuration file syntax. The file has the following groups:

- A group `[Type Table]` which lists the types and information how the debugger can identify whether the program is linked against the library.
- A group for each type which has information about how the value of such a type is displayed by KDbg.

In order to determine which type tables apply to the program being debugged KDbg lists the shared libraries it is linked to. Then it matches the names against the `ShlibRE` entries of all type tables. Those that match are used. If a type appears in several type tables, it is unspecified which one will be used.

KDbg's type recognition only works for libraries that are linked dynamically to the program being debugged.

## The `[Type Table]` group

This group contains the following entries:

- `Types1`, `Types2`, etc. These entries name the types, separated by commas. Each of the entries can list any number of types. The entries must be numbered consecutively (KDbg stops reading at the first gap), although an entry may be empty (i.e. contain no type at all). Sometimes the order in which the names are listed is important (see `Alias` types below).
- `ShlibRE`. KDbg uses this entry to determine if the type table applies to the program being debugged. For this purpose KDbg determines the shared libraries to which the program is linked. If any of the libraries matches this entry, the type table applies. The entry is a Qt regular expression. Note that back-slashes must be doubled because the back-slash is an escape character in the configuration file syntax.
- `LibDisplayName`. This entry is used in lists where the available type tables are listed to identify this type table.
  This is not used currently.
- `EnableBuiltin` lists extensions that must be enabled if this library is used. Currently, two builtins are supported:
  - `QString::Data` is used to display unicode strings of Qt's `QString` class. See below.
  - `QCharIsShort` is used only in connection with `QString::Data` to specify that a unicode character is stored in an object of type `short`. See `qt3.kdbgtt` for examples.

In the case of regular types the names of types should follow the output of the `whatis` gdb command less any `const`, spaces, or trailing `&`. If the type contains a a comma in its name, it must be escaped with a backslash. But note that the comma should not be escaped in the type's group (which is described in the next section).

In the case of template types the name can be arbitrary because the type's group will mention the template name and a type parameter list.

## The type's group

There is one group for each type that is named exactly as the type. Each group contains the following entries:

- An optional `Template` entry that specifies the exact template type name as it is reported by gdb's `whatis` command. However, it is possible to replace template parameter types at the top-most level by an asterisk `*`, which acts as a wildcard: It matches one template type argument that is reported by `whatis` (except that an asterisk in the last position matches all remaining template type arguments).
- `Display` determines how the value of the type is displayed by KDbg. The string must contain 1 to 5 percent characters '`%`'. These are replaced by the results of the expressions printed by the `Expr` x entries.
- One or more of `Expr1`, `Expr2`, etc. Each of them must contain one or more `%s` sequence, which will be replaced by the expression whose value is investigated. The so constructed expression is submitted to gdb, and the result substituted back for the corresponding percent character in the `Display` string.
- An optional `FunctionGuard` x that is associated with the corresponding `Expr` x. If the evaluation of the resulting gdb expression returns an error, the corresponding expression from `Expr` x is not evaluated. (This is used to guard function calls.)
- `Alias` names an alias type. If this entry is present, the type is treated like the specified type. That alias type must appear before this type in the `Types` x entries in the `Type Table`.

Currently the number of expressions per type is limited to 5. This can easily be changed if it's too restrictive, but I recommend not to go to that limit at all - it will slow down the debugging process.

KDbg recognizes a special extension that is used to display Qt 2.x's and Qt 3.x's unicode strings: If an `Expr` x is prepended with `/QString::Data`, it is assumed that the result of the expression is a pointer to a `QString::Data`. The value displayed is the unicode string that this instance of `QString::Data` represents (which can be `QString::null` if it is Qt's well-defined null string or `(null)` if the `unicode` member is the null pointer). See `qt2.kdbgtt` for examples.

Tip: It is not necessary to define derived types if they ought to be treated the same as the base class - KDbg can deduce derived types and uses the type specification of the (leftmost) base class. You can use the `Alias` entry to quickly specify that a type should be treated like a non-leftmost base class for a multiple-inheritance class.

## An example

The example shows how `QString` and `QRect` are defined in `qt3.kdbgtt`. Furthermore, the template type `QValueVector` is defined. This example applies to Qt 3.x, which is located in shared library whose name ends in `libqt-mt.so.3`.

    [Type Table]
    Types1=QString,QRect
    Types2=QValueVector
    LibDisplayName=libqt 3.x
    ShlibRE=libqt-mt\\.so\\.3$
    EnableBuiltin=QString::Data,QCharIsShort

    [QString]
    Display={ % }
    Expr1=/QString::Data (%s).d

    [QValueVector]
    Template=QValueVector<*>
    Display={ size=% shared=% capacity=% }
    Expr1=($tmp=(%s).sh)->finish-$tmp->start
    Expr2=(%s).sh->count
    Expr3=($tmp=(%s).sh)->end-$tmp->start

    [QRect]
    Display={ tl=(%,%) br=(%,%) }
    Expr1=(%s).x1
    Expr2=(%s).y1
    Expr3=(%s).x2
    Expr4=(%s).y2

This example shows these features:

- The name of the template type, `QValueVector` is irrelevant. The exact type name is specified under the `Template=` entry. It specifies a single wildcard so that it applies to all specializations.
- In order to evaluate the expression that was supplied in the `%s` only once, the result is stored in a temporary gdb variable and reused later in the same expression.
- Note that it is safer to wrap the `%s` in parentheses.