Caveats when debugging with gdb
There are some peculiarities of Free Pascalwhich you should be aware of when using gdb. We list the main ones here:
Free Pascalgenerates information for GDB in uppercase letters. This is a consequence of the fact that Pascal is a case insensitive language. So, when referring to a variable or function, you need to make its name all uppercase.
As an example, if you want to watch the value of a loop variable
count, you should typewatch COUNT
Or if you want to stop when a certain function (e.g
MyFunction) is called, typebreak MYFUNCTION
gdbdoes not know sets.gdbdoesn’t know strings. Strings are represented ingdbas records with a length field and an array of char containing the string.You can also use the following user function to print strings:
define pst set $pos=&$arg0 set $strlen = {byte}$pos print {char}&$arg0.st@($strlen+1) end document pst Print out a Pascal string endIf you insert it in your
gdb.inifile, you can look at a string with this function. There is a samplegdb.iniin appendix A sample gdb.ini file.Objects are difficult to handle, mainly because
gdbis oriented towards C and C++. The workaround implemented in Free Pascalis that object methods are represented as functions, with an extra parameterthis(all lowercase!). The name of this function is a concatenation of the object type and the function name, separated by two underscore characters.For example, the method
TPoint.Drawwould be converted toTPOINT__DRAW, and you could stop at it by using:break TPOINT__DRAW
Global overloaded functions confuse
gdbbecause they have the same name. Thus you cannot set a breakpoint at an overloaded function, unless you know its line number, in which case you can set a breakpoint at the starting line number of the function.
An experiment, built from development snapshots. Not the official Free Pascal or Lazarus documentation.
