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:

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:

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:

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 Exprx 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: