"step out" got me where I needed to be.
The benefit I see for the ability to turn off the assembler lines is I rarely (never) have any interest in seeing the assembler commands and having the ability to see the lines of my code that got me to where I was would often be interesting.
But when do you actually get it? Examples?I just tried, accessing an out of range index in a list. See the image.Yes the stack contains all those LCL lines...
But, the debugger automatically selected the first stack with my code.
- the source editor is at my code
- watches/locals are for my code
So, I really can just ignore the few lines in the stack window.
(But for stepping, I need to step out, or use a breakpoint)
As I said, that may not work 100% of the times. If it doesn't I need reproducible examples.
E.g., I foolishly created two var's for a record I was using which created a "somewhat" difficult bug. Had I been able to track back through the lines in my code directly from the call stack, finding the bug would have been much quicker and easier. That without having to doing the "step out" repeatedly. (I am more than a little lazy.)
Ok, half an example... Well, I don't know how you got to stop in that code of no-interest....?
Maybe you used the pause-button? Finding it (visually looking through the list) shouldn't be too hard? Unless there are like a dozen others first?
Stepping out is indeed a bit of an issue.
The problem however is not, just not to show the lines in the stack....
If for some reason you paused in that code that is not your code .... Then that is where the app is paused.
While a stack can be selected for viewing, for running, the app must run to exit from that code and go back to the calling frames.
There is indeed currently no solution (breakpoints may be faster than step out, if the code is not recursive)
What might be needed is a step command that will step to a "selected frame".
E.g. you could then do "Step to next line in selected frame" and it would step out all the way, and pause on the next line.
That doesn't exist yet, but may be useful.
Regarding Martin_fr's "Well, if it is lines in the LCL , then you can compile the LCL with debug info"; I am not aware of how to do that compilation; however, the debugger does trace into the LCL so I think I already have that. Do I?
Probably. But I don't think it solves the problem. The lines would still be there, and seeing some Pascal code from the LCL likely does not help you either.
Regarding "You can change the amount of lines that the stack shows," I have the line count set at the maximum of 50 but I never get that many lines, i.e., I just see a bunch of assembler commands that usually ends at 18 or 25 or so. "in some cases the stack can not show beyond a certain point" is interesting, I accept that for a fact but find it perplexing since the stack clearly has the commands back to the starting point in the '.lpr' file.
Well, actually there is no 100% guaranteed way of resolving the stack. Though it can still be improved in various ways (gdb is still a bit better).
Technically, each function puts on the stack the address of its caller. The debugger reads that, and knows the caller. => and repeat.
Except functions also but all kind of other stuff on the stack (e.g. local vars, and those can be pointers to other code, looking no diff from a return address). So the secret is finding the one place in the stack that gives the caller.
And that only works if the code follows certain rules. If it does not, then it wont work.
FpDebug currently has 3 ways to look for the caller: the base-register, dwarf, and dis-assembling. I plan to add more, but not sure when.
Recent
