If it has dwarf, it should work under both. (gdb and fpdebug).
Of course Lazarus needs to find the source files. Normally it looks in the project.
Though I would have do dig into the sources to see exactly how and where it looks.
=> ALL points IIRC
- A path in dwarf can be: just the file, relative path, absolute path (use objdump to find out)
- (for historic / old gdb based reasons) the IDE always first checks the filename only, within project and packages
- It may then use any path info...
- it should then ask the user to locate the file on the disk
The above usually happen if you stop inside a file / or select it in the stack.
If the file is already open in the editor, it should be found by just the filename+ext (so there will be issues if you have duplicate filenames) IIRC.
Watches will/should work.
Though in gdb, the IDE tries to Pascalize stuff. And that could harm watches against c.
(In gdb, use menu View > Ide Internals > Debug output to see what is sent to gdb)
In FpDebug that is probably less an issue. (Though the IDE uses addons, trying to detect ansi-string and dyn-array, worst case that picks up on some c data type....)
Either may expect "self" instead of "this". Since fpc sometimes writes "this", the IDE translates in most cases.
FpDebug supports a wide, but not full range of Dwarf-3.
Try basic values for watches first.
If then you have issues with specific data types, report that.
Note FpDebug strives to be 100% dwarf compatible eventually. So if gcc writes (valid) Dwarf, then even if FPC never writes it like that, it will be considered a bug in FpDebug if FpDebug does not know it.
FpDebug will parse expressions in Pascal style. So "foo->bar" does not work, and will not work.
The Expression parser is exchangeable, and if someone wants to write a c parser, well ok.
Watches with function execution may depend on calling convention. And currently it is only what Fpc uses. (registers + stack)
If you have other issue, please describe them.
(and use Lazarus 2.3 for testing)