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 ${TDEHOME}/share/apps/kdbg/types, where ${TDEHOME} is ~/.kde if it is not a defined environment variable. The file names end with .kdbgtt. Example: The type table for libtqt.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 regular expression is a TQt-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:
  • TQString::Data is used to display unicode strings of TQt's TQString class. See below.
  • TQCharIsShort is used only in connection with TQString::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. At the moment C++ template classes are not supported. 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 Exprx 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 FunctionGuardx that is associated with the corresponding Exprx. If the evaluation of the resulting gdb expression returns an error, the corresponding expression from Exprx 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 Typesx 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 TQt 2.x's and TQt 3.x's unicode strings: If an Exprx is prepended with /TQString::Data, it is assumed that the result of the expression is a pointer to a TQString::Data. The value displayed is the unicode string that this instance of TQString::Data represents (which can be TQString::null if it is TQt'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 TQString and TQRect are defined in qt3.kdbgtt. Furthermore, the template type TQValueVector is defined. This example applies to TQt 3.x, which is located in shared library whose name ends in libtqt-mt.so.3.

[Type Table]
Types1=TQString,TQRect
Types2=TQValueVector
LibDisplayName=libtqt 3.x
ShlibRE=libtqt-mt\.so\.3$
EnableBuiltin=TQString::Data,TQCharIsShort

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

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

[TQRect]
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, TQValueVector 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.