KDbg - User's Manual - Type Tables
Author: Johannes Sixt

Contents

# KDbg's Type Table

KDbg can display the contents of single members 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 type tables are located under `$prefix/share/apps/kdbg/types`. The file names end with `.kdbgtt`. Example: The type table for `libqt.so` is named `qt.kdbgtt`.

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. Each of them is a comma-separated list of type names. Each of the entries can list any number of types. (The types names can be distributed to several lines just so that the lines don't get excessivly long.) No blank space is allowed in these lines. 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 regular expression is a Qt-regular expression (the metacharacters `.*?[]^$\` are recognized in the usual way, but there is no possibility to group characters.)
- `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.

## The type's group

There is one group for each type that is named exactly as the type. At the moment C++ template classes are not supported. Each group contains the following entries:

- `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 exactly one `%s` sequence, which will be replaced by the expression whose value is investigate. The so constructed expression is submitted to gdb, and the result substituted back for the corresponding percent character in the `Display` string.
- `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 `QObject` are defined in `qt.kdbgtt`. Additionally, `QTableView` is defined as an alias of `QObject`. This example applies to Qt 1.x, which is located in shared library whose name ends in `libqt.so.1`.

    [Type Table]
    Types1=QString
    Types2=QObject,QTableView
    LibDisplayName=libqt 1.x
    ShlibRE=libqt\.so\.1$
    [QString]
    Display={ % }
    Expr1=(%s).shd->data
    [QObject]
    Display={ name=% #chld=% }
    Expr1=(%s).objname
    Expr2=(%s).childObjects->numNodes
    [QTableView]
    Alias=QObject

Note that it is safer to wrap the `%s` in parentheses.