View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0038104||Lazarus||Debugger||public||2020-11-20 11:43||2020-11-26 23:25|
|Reporter||De2fpc||Assigned To||Martin Friebe|
|Status||resolved||Resolution||no change required|
|Fixed in Version||2.2|
|Summary||0038104: Debugger doesn't work correctly when using local procedures, jumps to a wrong line number in this unit using f7.|
|Description||When using an unit, thaut contains procedures with local procedures, the debugger jumps to a wrong line number in this unit using f7. (see attached project)|
furthermore if you set a breakpoint in procedure p1 the debugger stops somewhere else in the source.
(using win32 version)
|Steps To Reproduce||see attached project|
|Tags||No tags attached.|
|Fixed in Revision|
project1.zip (1,976 bytes)
This issue may not be fixable as it appears to be caused by gdb.
First of all:
- My analysis of this, is based on your example with empty methods.
- If I add content (e.g. "write(1);" into the procedure, then all appears to work for me.
If you get the wrong behaviour with none-empty methods, then there may be more to look at. Or it could still be the same issue. (I could not test that yet).
However, even with none empty methods, the below may help.
There are several settings that may fix the issue.
1) Most important: In Project > Project Options > Debugger
change the "debug type info" to "dwarf with sets"
2) If for some reasons you want to use "stabs" (or default, which afaik on win32 is stabs) then use -O- (optimization level 0)
Mind that dwarf is in almost all cases better than stabs.
3) If you continue having problems, there is a new alternative debugger (that is available in 2.0.10): FpDebug.
Install the package LazDebuggerFp
Tools > Option > Debugger: change to FpDebug
This only works with dwarf, and enforces dwarf (this can be used with dwarf-3)
You may run into another know gdb issue. "Step over F8 will do step into":
In the debugger settings, in the property grid is an option "FixIncorrectStepOver"
(FpDebug does not have this problem)
Background (just for info):
This is probably caused by GDB trying to detect (and skip) "begin" lines. Normally gdb attempts to step to the line after the "begin" (in your case the "end" line).
However with -O1 the code appears to be so small that gdb goes to code of the next procedure.
GDB getting this wrong, may also bu partly caused by how FPC creates the line info for the methods below (those methods are never called, and apparently that leads to some differences in the line info / potentially wrong addresses or missing relocation info). Not yet fully analysed. But nothing that could be quickly changed
Please check if the "workarounds" fix the issue for you.
Especially if you get the issue in none-empty procedures?
If the workarounds help you, then the issue will get closed as "not fixable".
If the problem persists with dwarf AND no-optimization, then more info may be needed for me to reproduce it. In this case also check if "fpdebug" can handle the issue.
||yes the setting "debug type info" to "dwarf with sets" the problem is solved for me thanks|
|2020-11-20 11:43||De2fpc||New Issue|
|2020-11-20 11:43||De2fpc||Status||new => assigned|
|2020-11-20 11:43||De2fpc||Assigned To||=> Martin Friebe|
|2020-11-20 11:43||De2fpc||File Added: project1.zip|
|2020-11-22 17:26||Martin Friebe||Note Added: 0127115|
|2020-11-22 17:29||Martin Friebe||Status||assigned => feedback|
|2020-11-22 17:29||Martin Friebe||LazTarget||=> -|
|2020-11-22 17:29||Martin Friebe||Note Added: 0127116|
|2020-11-23 03:09||Martin Friebe||Relationship added||related to 0038117|
|2020-11-26 17:36||De2fpc||Note Added: 0127200|
|2020-11-26 17:36||De2fpc||Status||feedback => assigned|
|2020-11-26 23:25||Martin Friebe||Status||assigned => resolved|
|2020-11-26 23:25||Martin Friebe||Resolution||open => no change required|
|2020-11-26 23:25||Martin Friebe||Fixed in Version||=> 2.2|
|2020-11-26 23:25||Martin Friebe||LazTarget||- => 2.2|