Graeme Geldenhuys wrote 11 lines
On Sat, Feb 21, 2009 at 12:49 AM, Hans-Peter Diettrich
wrote:
> In most cases I cannot inspect local variables, due to "no such symbol
> in context" errors, even with fully disabled optimizations.
>
This is exactly the errors I get. I develop under Linux only, so it
doesn't seem to be a platform issue. I gave up trying the integrated
debugger and simply use Log(..) or Writeln(...) calls now
It is true that there are cases where GDB does not find Symbols, until this can be fixed in a better way, here are a few cases and workarounds
1) properties
This is apparently the most common case? GDB has no concept of properties. Also properties can refer to functions. Possible workarounds:
a) if a property refers to a Variable, use CodeTools to find the variable name, and expect the Variable. Usually property abc, will point to variable Fabc
b) if the property refers to a method, there is no workaround, since currently you can not force GDB to execute any method. Executing the Method could also change the state of the debugged application.
2) Nested Procedures
GDB does only see the current stack frame.
Procedure SomeObject.ABC
var x: integer;
Procedure Nested
begin
end
begin
end
While in "Nested" gdb can NOT see anything that belongs to ABC. (this is it can not see "x", and it can not see "self" (the object), or any variable on the object)
Possible Workaround:
Open the Stack Window, and change the current frame. I know this is a bit dull, because you have to change it after each execution step.
2a)
The same applies to hints in the source window. *Variables* will only show if the stackframe is correct
3)
Sometimes Variables are pointers in GDB, where they are not in Pascal.
if you type SomeObject as a watch it may just say "TSomeClass 0x23ab76" => try typing SomeObject^
4) Dynamic arrays
See the following post for a workaround (again it is too complex for every day use, but it may help for desperate occasions) http://forum.lazarus.freepascal.org/index.php/topic,4763.msg22954.html#msg22954
