Forum > Other
Lazarus, FpDebug and GDB
440bx:
Hello,
I was wondering if there is a way to use either GDB or FpDebug _in Lazarus_ to debug C/C++ code created with g++ at the source level.
That's the question: can a C/C++ file executable with Dwarf symbolic information be debugged using Lazarus with FpDebug or GDB ?
Thank you for your help.
Martin_fr:
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)
Martin_fr:
--- Quote from: Martin_fr on November 28, 2022, 11:43:35 pm ---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.
--- End quote ---
To clarify. There is a difference between
- FpDebug
- LazDebuggerFp
FpDebug is (more or less) generic. And should be.
- The parts that "detect ansistring", that is the parts that do Fpc specific work are add ons. They are not active in FpDebug by default. However in the IDE they are always loaded.
- The pascal parser for watches in in FpDebug, but it is exchangeable. (Again the IDE chooses / and also it is currently the only choice)
LazDebuggerFp integrates this into the IDE. LazDebuggerFp is therefore not striving for more than Fpc support.
Though for the majority of cases, all the decisions happen in FpDebug. And LazDebuggerFp does not interfere.
Martin_fr:
Since the IDE needs a project, you need to setup a dummy project.
Or well, if your c file is linked to a pascal app, then you have a project.
You can just try by having the c file open in the editor. Or try to add it to the project, if there are any issues (mainly about if the blue dots in the gutter happen / that is the file is found in the exe).
440bx:
@Martin_fr
Thank you!... lots of great info there. :)
I'm currently getting "up to speed" with DWARF debug information. I've been reading all the documentation as well as objdump source and DwarfViewer (for the time being.) I've already noticed that even though DWARF is a standard, there are "variations". For instance, from what I've read LLVM clang DWARF symbolic information has a bit of its own "personality" but, at least for now, my interest is mostly limited to the debugging info emitted by FPC, once I've got that down, I'll dig into what the GNU compilers emit (and most likely limited to C and C++.)
I asked the question because, it would be helpful/nice to debug objdump using the combination Lazarus/FpDebug (or GDB if unexpected problems arise with FpDebug with C code.)
Thank you again, the information you provided, I have no doubt will prove very useful.
Navigation
[0] Message Index
[#] Next page