Ok there seems something wrong with GDB.
But it could also be a problem in how FPC generates debug info.
I dont think it is an issue with how you build fpc (since you use trunk?). I am not aware of any compiler options that would cause this.
It may though be that fpc trunk has not yet known issues in generating debug info.
There is also a small issue in the IDE, though it wouldn't make a difference here. More below.
-------------------------------
Before I go into technical details:
Check in "project options" > Debugging: "Type of debug info".
You might change this to "Dwarf with sets"
You can also try "Dwarf 3" (but that may need an even newer gdb. / try it though, it is fine unless you get "gdb stopped working")
You may also want to change that for the LCL (package options)
Or add -gw (or -gw3 for dwarf3) to menu: Tools > Configure Build Lazarus: Custom options)
You also may want to try an even newer GDB, but I do not know where to download that for win64.
Alternatively you can build your fpc (the RTL) with -O-1
Maybe gdb will get better results if the code is not optimized.
------------------------------------------------------
The technical bits....
-- Problem 1)
GDB thinks indeed that some code from the unit DB: .AsText and some methods called by this function are new lines in your code and it stops there.
Though FPC did not seem to have inlined them.
So after you hit your breakpoint, when you first press F8,
DB believes that the next line starts in TSTRINGFIELD.SETASSTRING
GDB actually stops in that method.
-- Problem 2)
But the IDE notices that this code does not have debug info. So the IDE tries to find a line on the callstack. In this case this is wrong by the IDE.
The IDE should expose the GDB (or FPC) error at this point.
-- Problem 3)
Because TSTRINGFIELD.SETASSTRING is in the RTL, it is optimized. It does not allow to find the correct caller. (This is a feature / but it does not matter, as there should be no attempt to look up the caller)
So instead of your code (which called SetAsString), the method one further up on the stack is found. This is the code calling "OnClick".
-------------------------
To recap.
After F8 you have the following callstack
1) TSTRINGFIELD.SETASSTRING
2) f_main_MyProject.pas:1140
3) menuitem.inc 83 " OnClick() "
You actually are at 1.
The IDE tries to get 2
But it gets 3, and displays 3
2 will be hidden, even if you display a stacktrace. This is because the RTL is compiled with optimization.
The optimization of the RTL normally would not matter, if not the IDE would try to be too clever....
But even without the IDE trying to be clever, the problem would still be that gdb stopped inside SetAsString.
-------------------------------
On further steps, gdb stopped in various methods in the RTL that are called by SetAsString.
Due to the IDE trying to be too clever, this sometimes shows your code. This explains why some F8 just stay on the same line. GDB stepped to another method, but the IDE finds your line.
I reported the IDE part
https://bugs.freepascal.org/view.php?id=32978======
"optimized" code in the RTL.
Any reference to "optimized" in the above is about fpc compiling some methods without stackframe (i.e. the code does not save the stackpointer as base-stackpointer).
This optimization means that a caller gets hidden on the stack.
It may also interfere with gdb analysing the code. (Though this I have never observed so far)