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): It me files that belong to a shared library. Such breakpoints will be marked as orphaned if the program is not active. Orphaned breakpoints are not effective. In order to make them effective, the program must stop at a time when the shared library is loaded. For this it is usually sufficient to set a breakpoint in main(). At the time when this breakpoint is hit, the orphaned breakpoints in the shared library become effective.

  • Debugging multi-threaded programs on NPTL-enabled Linux systems (kernel 2.6.x or later and glibc 2.3.x or later) may sometimes fails; gdb stops the program at unexpected instances. In this case the following may help (using bash):
    LD_ASSUME_KERNEL=2.4.19 kdbg myprogram
    
    I.e. you run KDbg from the command line such that the old Linuxthreads implementation is used.
  • ./usr/share/doc/kde/HTML/en/kdbg/types.html0000644000000000000000000002037011651066134017250 0ustar rootroot