Recent

Author Topic: Lazarus, FpDebug and GDB  (Read 1764 times)

440bx

  • Hero Member
  • *****
  • Posts: 3921
Lazarus, FpDebug and GDB
« on: November 28, 2022, 10:14:46 pm »
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.
« Last Edit: November 28, 2022, 11:24:20 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #1 on: November 28, 2022, 11:43:35 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #2 on: November 28, 2022, 11:52:46 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.

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

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #3 on: November 28, 2022, 11:55:27 pm »
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

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #4 on: November 29, 2022, 12:33:59 am »
@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.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #5 on: November 29, 2022, 01:29:52 am »
"personalization" well each programmer who read the dwarf docs may have ended up with their own understanding....

Gdb (at least up to version 10) had some assertions, that where plain wrong. In same cases, if a structure contained a pointer to an array, gdb would complain that the array did not fit into the size of the structure.... (well, only the pointer is in the structure) ...

But then, they tested against the dwarf they had, they tested against dwarf as produced by gcc.
Same as I tested against dwarf by fpc (which had it's own interpretations too).


fpc also has

-godwarfcpp

To write dwarf that is more similar to what cpp would write (or so is my understanding).

FpDebug can read that. But it does not do any "special tricks" with it.
Dwarf doesn't have Ansistring. Fpc either writes "^array of char" or "^char".
FpDebug still can in some cases differentiate, because fpc emits some optional fields differently... But FpDebug does that only for the normal fpc dwarf (and mainly dwarf 3)


440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #6 on: November 29, 2022, 01:45:59 am »
I haven't reached the point where I have to deal with all the "subtleties" resulting from the different interpretations.

For now, I am limiting myself to solidify my knowledge and understanding of DWARF and, the information you provided about GDB assertions are definitely something I will keep in mind.

On a possibly related note, are you aware of any "unusual" assertions (or anything else) in objdump related to DWARF ? (objdump along with Pascal code associated with FpDebug and DwarfViewer are my main sources of "guidance" for the time being.)

Thank you again for all that info.  This is good stuff.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #7 on: November 29, 2022, 02:01:34 am »
DwarfViewer assumes 32bit for "dwarf expressions" (DW_OP_*) => hence sometimes the translations are not ok.
DwarfViewer was just "hacked together"...

FpDebug has some fixes in 2.3.
I haven't run into any asserts, and I have an extensive testcase based on an FPC compiled exe (over 10k watches are tested).
FpDebug probably has to few checks. So the danger is towards it doing illegal mem access, or the like.

Currently know issue
- "type foo = object" requires fpc 3.3.1
- even then: inherited old object don't always show all fields (not sure where the blame lies) / could also be "generic inherited old style object"

---
I hadn't had issues with objdump yet.

---
properties with getter function don't work, and need custom dwarf tag => Joost is on that.

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #8 on: November 29, 2022, 03:07:03 am »
DwarfViewer assumes 32bit for "dwarf expressions" (DW_OP_*) => hence sometimes the translations are not ok.
That is really good to know. 

I hadn't had issues with objdump yet.
and so is this.

I have an extensive testcase based on an FPC compiled exe (over 10k watches are tested).
Would that test case be useful to someone getting their "bearings" with DWARF (in this case, me) ?  if the answer is yes, is it something that you could make available ?

Thank you yet again.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #9 on: November 29, 2022, 09:36:40 am »
I have an extensive testcase based on an FPC compiled exe (over 10k watches are tested).
Would that test case be useful to someone getting their "bearings" with DWARF (in this case, me) ?  if the answer is yes, is it something that you could make available ?

It is available. In the testcase folder. https://wiki.freepascal.org/Lazarus_Debugger_Implementation#Testcases_.28Backend.29

Probably not useful.
It generates a huge Pascal source (from the TestWatches template).
It needs a configured list of fpc compilers / diff versions.
It then compiles, runs, steps through and evals watches.

It does not check the dwarf itself, it checks (for each fpc version) that FpDebug returns the correct value for that watch.

It (the generated test app) will crash lldb (at least the versions I tested some while back) because it passes several 100 params to some subroutines.


It depends what you are looking at.
And if you are more about dwarf or getting bearings in the fpdebug sources.

In the FPC sources you find dbgdwarf.pas
Which afaik generates all the dwarf.
Maybe if you look at some of the appenddef_* methods (like appenddef_array), but dwarfviewer/objdump will be an easier way to see the result.




440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #10 on: November 29, 2022, 02:20:01 pm »
but dwarfviewer/objdump will be an easier way to see the result.
That's the impression I got too.  Currently, I am focusing on DWARF because I believe it's necessary to see how to use it properly.

Thank you for all the guidance.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #11 on: November 29, 2022, 02:26:03 pm »
Currently, I am focusing on DWARF because I believe it's necessary to see how to use it properly.

Out of curiosity: Are you writing/amending a compiler, linker or debugger?

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #12 on: November 29, 2022, 03:07:53 pm »
Out of curiosity: Are you writing/amending a compiler, linker or debugger?
The "immediate" goal would in some ways approximate a debugger.  The first step is to create a "normalized" structure for debugging symbols because I want the resulting program to handle both DWARF and PDB and I want the handling to be fully transparent.

My current thinking is, see what I get from DWARF and how, see what I get from PDB and how (APIs are there for the PDB stuff, that's pretty much taken care of as far as obtaining the data), massage that data into a new database of symbols in order to provide full transparency and dynamic extensibility.  That's "step 1", already a fair amount of work.

The true objective of the program is to analyze the executable code (similar to what IDA pro and Ghidra do) and have the analyzer create debugging symbols that make it reasonably easy and quick to take the analysis further.   It's an ambitious project (maybe even a pipe dream) that is obviously going to take "some time" ;)  (One thing I've decided is that I will _not_ write the dis-assembler - requires too much testing to ensure it's right.)

The goal is to end up with something that is more powerful and flexible than the current crop of disassemblers/decompilers.  Most likely a pipe-dream <chuckle>

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9754
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus, FpDebug and GDB
« Reply #13 on: November 29, 2022, 03:37:21 pm »
(One thing I've decided is that I will _not_ write the dis-assembler - requires too much testing to ensure it's right.)
Oh, very true....

You may be able to use the one in FpDebug. It does return a record for each instruction (and then only translates that to text). So you can use that data for analysis.
(Of course, hoping it returns correct data, but since it is part of the IDE, bugs will eventually be found)


440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: Lazarus, FpDebug and GDB
« Reply #14 on: November 29, 2022, 03:57:24 pm »
You may be able to use the one in FpDebug. It does return a record for each instruction (and then only translates that to text). So you can use that data for analysis.
(Of course, hoping it returns correct data, but since it is part of the IDE, bugs will eventually be found)
I would prefer having everything in Pascal.  In the case of the disassembler, I'm leaning towards ZyDis because there are a fair number of eyeballs continuously involved in it (and seems to be very well tested.)  I used Distorm4 in the past and I really like it (not to mention that I already have code to implement a few basic things using it) but, it seems to only (or mostly) be supported by its author and it currently still does not handle some instructions.

Honestly, my conscience bothers a little for not using a disassembler written in Pascal (either FpDebug's or the one in CheatEngine and, yes, I would prefer using the one in FpDebug, leading to greater chances of giving something back to the community.) The problem is, the goal is already quite ambitious and I am concerned that "good intentions" could contribute to not getting it done.

But, for whatever it may end up being worth, I intend to make the project fully open source once I have it running to my satisfaction (or at least somewhat close to my satisfaction.)

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018