Lazarus
Using the Lazarus IDE => Debugger => Topic started by: aducom on May 05, 2022, 09:36:13 pm
-
I have Dwarf enabled and due to some error in my code, I got an error message that a file could not be created. With GDB it jumps straight into the source code and shows the line where it is failing. With dwarf, I get the error message, but the assembler form pops up and that gives no clue where in my source code it is going wrong. I'm new to this debug format, so I probably have set some preferences wrong. How can I achieve similar behavior as the GDB?
-
First of all, GDB uses DWARF too. Except on Win-32 bit, maybe some other 32bit targets, and maybe some embedded targets.
So you probably mean "FpDebug". (which is the debugger that asks you which DWARF version you want).
- And just to say: for your problem it does not matter which DWARF version you selected. (this only matters for watches).
Well to be exact:
- "DWARF" (and stabs) are data-formats that FPC uses to provide info for any debugger.
- GDB can use stabs, and all DWARF formats (though it crashes easily with DWARF-3 generated by FPC)
- FpDebug can only use DWARF.
- FPC
-- can write DWARF for all major targest (Win, Linux, Mac / 32 or 64 bit)
-- can write stabs only for very few targets
-- the IDE setting "Automatic -g" for "Type of debug info" is decided by fpc. It is stabs only for those few targets that support stabs, otherwise DWARF.
In order to see, if it is FpDebug or GDB that you use:
=> Menu: Tools > Options - Tab: Debugger > Backend
=> Menu: Project > Project Options - Tab: Project Options > Debugger
(each project can override the selection)
So when you compare with GDB, was that the exact same error in the exact same application?
To make sure, you can change the debugger. Lazarus 2.2 comes with both: FpDebug and GDB.
That way you can:
- test that the exact same error is indeed handled different by the 2 debuggers
- temporary work around the issue until solved (requires your feedback please).
When you get the Assemble window
- What are the addresses of the code?
0x7fff...... / 0x00004..... / 0x01004..... / other ?
- Does it show any function names?
- What is shown in the "stack window" ? (Also "thread window")
Possible causes for your problem
- Packages don't use DWARF.
Debug info is generated for the code you wrote (your project). But also for packages (LCL, ...).
They have individual settings. The IDE only updates your project.
If you happen to be an a "default to stabs" target (eg Win 32bit) then packages will still be stabs (and inaccessible to FpDebug).
Either
- Menu: Tools > configure build Lazarus => In the field "Custom Options" add -gw
- change each package.
- go to Project Options > Additions and Overrides => add an override (there is a page on our wiki...)
- You code belongs to on old/TP -style "object"
type TFoo = object
procedure DoFoo;
end;
- Your crash is somewhere in the Kernel / Win-API
FpDebug can not always unwind the stack, for 3rd party code (like Win-API, kernel, system libs...)
What is your OS?
64 or 32 bit?
And are you using the up-to-date Lazarus 2.2? (Asking just in case, some people don't => that's ok, but matters for finding out what causes the issue)
-
Thank you for your detailed answer!
I did a fresh re-install of the latest Lazarus version running on Win10/64 and when you do so then, FpDebug is standard. I noticed it because I got a different style of messaging, and a start-up question about what Dwarf version to use.
So if I get some kind of error like 'unable to create file.... the system cannot find the path specified (emulated the problem), then click break should bring me to the code line that causes the issue. It didn't but brought up the assembler window with some kind of 'island' code (a code block with a hand full lines in a zero block). But today, I tried to replicate (after using gdb), and apparently, it works now. So I'm not sure if it is caused by the fresh install or if there are some other circumstances.
Of course, I like to help, I will try to replicate and report here if I can...