F8 step-over sometimes goes into assembly code

[ad1mt]

F8 step-over sometimes goes into assembly code.
I'm puzzled about this... can anyone explain why this sometimes happens.
Thanks.

[Martin_fr]

There is a lot of info missing...

Lazarus version? (2.x / 3.0 / 3.99)
Fpc version?
OS?
32/64Bit?  (All the same for OS, Lazarus, and project? or cross compile?)
Debugger Backend (FpDebug, Gdb, Llld+FpDebug)
Did you compile With optimization OFF or Level-1?

If not FPDebug, and if 32 bit: Stabs or Dwarf?

Any indication on where the show assembler code is, in relation to the code that you were stepping?
E.g. What does the "Callstack" window show? Is your code in the list (Where)?

Does the asm window show any names in-between/ above the asm statements (anywhere but NOT in the comments)?

[ad1mt]

I hoped this might be an easy question to answer, but I can see its not. It does not bother me enough to spend time investigating/reporting.

[Martin_fr]

Well, it's a bug. And one that I am not aware off.
So in order to fix it (or even just guess what it may be), I need some starting point.

[Edson]

I have the same problem in Windows 10. It happens in some cases, like when I do F8 in an instruction that have a string comparison.

I work at level 1 for optimization and Dwarf with sets.

[Eugene Loza]

Oh, so it can actually be a bug? I always thought it's intended behavior (when a line of code simply cannot be displayed for some reason). Always ignored the feature, but some units like include flies (seh64.inc) or dotted unitnames (generics.collections.pas) sometimes fail to resolve properly, especially during an exception. So I should be on lookout for those...

[Martin_fr]

I have the same problem in Windows 10. It happens in some cases, like when I do F8 in an instruction that have a string comparison.

I work at level 1 for optimization and Dwarf with sets.

Your assembler Window tells me you are using gdb as backend. And indeed, with GDB this does happen.
(I am not sure if it is a gdb issue, or something to do with the way fpc wrote the debug info.)

However, it works fine (at least for all my testing) with FpDebug.

I would highly recommend to switch to FpDebug. Tools > Options > Debugger > Backend.
Most likely the toolbar on top of the page already has an entry FpDebug that can be selected (If not click "Add", and select in the dropdown in the middle of the page).

[Martin_fr]

Oh, so it can actually be a bug? I always thought it's intended behavior (when a line of code simply cannot be displayed for some reason). Always ignored the feature, but some units like include flies (seh64.inc) or dotted unitnames (generics.collections.pas) sometimes fail to resolve properly, especially during an exception. So I should be on lookout for those...

That is a misunderstanding.

F8 should step to the next line of Pascal code.  So the next line should be known, and should be reached.
(That is, unless it is at the "end;" of a function, and leaving the function, and the caller has no debug info, then there would be no source to show)


So the bug here is that F8 does not  step to the next line as expected. The bug is that F8 stops somewhere else. => Then the asm Window opens. (And while there are cases, where the asm window opens incorrectly, in this case - if one ignores that the F8 failed - it would be correct).

After all, if it is  "F8 step over" in GDB going wrong, then gdb tells the IDE that your step ended at this asm statement. In other words gdb tells the IDE you wanted to purposely step to this asm statement for which no source is known. Once the IDE believes that was what you wanted, then it is correct to show the asm window. 
Of course with F8 this can only happen due to the prior bug in F8.


About the asm Window in other cases.
When an exception happens and the app gets paused, then the actual "raise" in the RTL may not have debug info. Maybe not even the caller (like TStringList in classes). But some code with debug info should have called the code that caused the exception, and ideally the debugger should find it and go there. That does sometimes fail. That is a bug. 
I have to check, I recall having done some work on it to improve it (but not sure how well the result was  / And also how it affect gdb/lldb as it was likely tested for fpdebug).

There may be other similar cases.
 

Anyway, whatever the cause is. And whatever the config (gdb, fpdebug, lldb) it is always good to mention it. Even if in some case (like gdb) the chances are slim that anything can be done....

There are still - after excluding 3rd party like gdb - enough cases that simply aren't fixed because I don't know they exist. The debugger can be run in so many different setups, that it is impossible to go through all of them myself. E.g. For my development I often need an RTL with debug info. But that changes fundamentally how many things are handled in the debugger. So I don't always get the out of the box experience.

[Eugene Loza]

Thank you! "Tools > Options > Debugger > Backend" Tells me that I'm using FpDebug. I'll then just pay more attention to such cases and will be able to ask more specific questions

[Eugene Loza]

E.g. remembered a bug I've had a very hard time tracking two weeks ago:

Code: Pascal  [Select][+][-]

1. program Project1;
2. uses
3.   Generics.Collections, Generics.Defaults;
4.  
5. var
6.   Dict: specialize TObjectDictionary<String, TObject>;
7. begin
8.   Dict := specialize TObjectDictionary<String, TObject>.Create([doOwnsValues]);
9.   Dict.Add('a', TObject.Create);
10.   Dict.Add('a', TObject.Create);
11. end.

Second "Add" crashes because the key already exists, but it tries to look for "Generics.Dictionaries" in the project folder not in FPC sources. And "resurfaces" from the assembler window only inside of "try..except" it was wrapped in.

Note, I'm using FPCUpDeluxe to install FPC+Lazarus so hypothetically it can affect the paths.

[Martin_fr]

Code: Pascal  [Select][+][-]

1. program Project1;
2. uses
3.   Generics.Collections, Generics.Defaults;
4.  
5. var
6.   Dict: specialize TObjectDictionary<String, TObject>;
7. begin
8.   Dict := specialize TObjectDictionary<String, TObject>.Create([doOwnsValues]);
9.   Dict.Add('a', TObject.Create);
10.   Dict.Add('a', TObject.Create);
11. end.

Second "Add" crashes because the key already exists, but it tries to look for "Generics.Dictionaries" in the project folder not in FPC sources. And "resurfaces" from the assembler window only inside of "try..except" it was wrapped in.

Please report this. (It happens with 3.2 and 3.99

I can't currently exactly tell where it goes wrong. Probably will need a team effort (that is me and "have to find who").

The debugger gets filenames (sometimes with a simple include folder, relative to a package main dir). The debugger then calls the packager in the IDE (I think at least its the packager), and that resolves pathes.

I can't tell why it does not work for this one....
- On a first glance, I haven't spotted any funny business due to it being a specialization (there had been issues with fpc writing incorrect debug info / but *seems* ok here(
- Maybe the dotted name. I have seen work on that for the IDE. But not sure where that stands now.

Unfortunately for you, it's not going to make it into my top-priority list. So may take a while.

Fortunately for you there is a workaround.
  Tools > Options > Debugger > General

There is an edit "Additional Search path"
Put the path to the file into that. E.g.:
   C:\fpc\source\packages\rtl-generics\src\inc\

If you report it, copy the following (thanks):
"There may be an issue that the debuggers additional search path must include the '/inc', because that is also given in the dwarf info"

[Martin_fr]

Also it is an interesting question, if failing to find a source file should
- go further out on the stack to find a caller with a source that can be located
- show the asm.

In either case, the question only arises due to a prior fault. (in this case bug, but could be a user that deleted a file).
As such, this is how do deal with a follow up problem.

And, if the IDE tried to avoid the asm window in that case, it could encounter 10 further different missing files, asking for each of them. That would hardly be better than the asm window, and then the option to search on the stack.

The other option would be: Not to ask at all.

Ignore that the compiler said the file should exist. Treat
- compiler did not include debug info
- file is not on disk
as identical.

Then the stack could be searched.

Downside, you don't have the option any more to locate the file, and see the code in the file.
(I have encountered that / though really long ago, when this error was far more common / and searched for the file and opened it -- so the option to do so is more than theoretical)

Could be a global option. But given that (when the current bug is solved) this should rarely happen, not on the "near future" list.

[Eugene Loza]

Unfortunately for you

Oh, that's perfectly ok I lived with this kind of issues since around 2009 and didn't even know it's something that is not supposed to happen and should be reported

Started filing the report but then figured out I'm not sure if I should report it to FPC or to Lazarus issue tracker? Sounds like FpDebug is not strictly part of Lazarus, but the issue manifests for me in Lazarus and I don't even know how to use a debugger in pure FPC.

[Martin_fr]

Unfortunately for you

Oh, that's perfectly ok I lived with this kind of issues since around 2009 and didn't even know it's something that is not supposed to happen and should be reported

Started filing the report but then figured out I'm not sure if I should report it to FPC or to Lazarus issue tracker? Sounds like FpDebug is not strictly part of Lazarus, but the issue manifests for me in Lazarus and I don't even know how to use a debugger in pure FPC.

In this case Lazarus.

FpDebug is Lazarus.
And yes, it reads input by FPC, which could in some other cases be buggy. But then, if that is the case, I can still move it. (In the case "generic.collection" not found, it isn't)

[Martin_fr]

Code: Pascal  [Select][+][-]

1. program Project1;
2. uses
3.   Generics.Collections, Generics.Defaults;
4.  

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40862