Debugging Lazarus/FpDebug

[440bx]

Hello,

I'm seeking advice on how to proceed to debug FpDebug.

I currently have the trunk versions of FPC and Lazarus installed and working.  I also have the stable version of FPC and Lazarus installed and working.

I'm guessing that the most logical thing to do, at least initially, is to debug the trunk version using the stable version. If there is a "better" way, I'd like to know about it.

I've noticed that it is possible to run multiple instances of the same Lazarus installation opening the possibility of debugging trunk with trunk and/or stable with stable but, I am a bit concerned that running two instances of the same installation may cause problems.  Is this concern warranted ?

I've googled to locate any "documentation" on FpDebug but, I haven't really found anything that is for the development of Lazarus and/or FpDebug.  Links to things I should read would be most appreciated.

Lastly, any pertinent information anyone wishes to share that may be helpful is definitely welcome.

Thank you.

[Martin_fr]

Well, I usually use Lazarus trunk, to debug FpDebug. (Mostly on Windows, but should be similar on Linux, if you take care not to freeze X-Server.)

IDE-1 debugs IDE-2 debugs some test-project. => So the FpDebug in IDE-2 can be debugged from the IDE-1.

If I make changes that may be unsafe, then I keep a copy of the IDE's executable. I.e. I have a "lazarus.good.exe" in my lazarus folder, right next to the "lazarus.exe". They can both run in that folder.
If I start the debugger on "lazarus.lpi" it will start the "lazarus.exe".

Mind, that it can be helpful, to set "Run Params" to have a "--pcp=..." for the debugger IDE. Then the debugged IDE can start with different Window positions. (even be marked with  a different color scheme for the source editor (really prevents mistakes)).
But make sure to keep settings like "custom options" to build IDE unchanged. They affect packages too, and if they differ, the 2 IDE compete on recompiling everything.


Out of curiosity, what to you try to find by this debugging?

[Martin_fr]

There isn't a internal documentation on FpDebug.

Depending what you look to understand:

- Windows API
https://learn.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-waitfordebugevent
https://learn.microsoft.com/en-us/windows/win32/debug/writing-the-debugger-s-main-loop

- man ptrace

- DWARF-3
spec https://dwarfstd.org/

- The involved file formats
pe and/or elf

[440bx]

Thank you very much Martin... very useful

My knowledge of the Windows debugging API is reasonably good.  My knowledge of DWARF still needs some work but it's definitely better than it was a few months ago (I think I'm about "half" there.)  The PE format, I know that reasonably well too.  I have no knowledge of the ELF format and I'm hoping it can remain that way (I'm not involved with Linux therefore I hope my lack of ELF knowledge won't be a real problem.)

Out of curiosity, what to you try to find by this debugging?

My "dream" is to improve the assembly level debugging of FpDebug.  I say "dream" because when I read OOP code, I can't even figure out which way is up, OOP will, by far and away, be my biggest problem and, I'm not even sure I'll be able to overcome it but, I'm going to try. 

At least, now I have a place to start.   Thank you again.

[Martin_fr]

Then your point of entry will be
components\fpdebug\fpdbgdisasx86.pp
ide\packages\idedebugger\assemblerdlg.pp

And the chain of units inbetween. (DebuggerIntf)

There are 2 DebuggerIntf, as I am gradually trying to move to a newer one. (the old one was when we had only one backend....)

The newer one, is the one with the interfaces.

It doesn't have anything for the asm yet. So that goes all via the old one.


There is somewhere some horrible code that retrieves ranges, merges them, and arghh.
"PrepareRange" and related.

Really bad code.
But really hard to replace, because then you need to deal with the gdb and lldb backends too....



For an idea how to add stuff, search the git log for the recent addition (in 2023) of "links" in the dissembler. (ctrl click to follow jmp and call statement)

Search the log of just the  ide\packages\idedebugger\assemblerdlg.pp => that should get you the commit(s).


As for the fp debug disass.

TX86Disassembler.Disassemble disassembles into TInstruction => where the opcode is an enum.

Stringification happens in a 2nd step.

That is so the debugger can internally read code, and does not need the string. (e.g. check if there is a call statement).

Unfortunately (and that is a todo), the operands are still directly returned as strings. They should be represented as some data-structure...
That is a todo....

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40556#note_1604325987

[Martin_fr]

My "dream" is to improve the assembly level debugging of FpDebug.  I say "dream" because when I read OOP code, I can't even figure out which way is up, OOP will, by far and away, be my biggest problem and, I'm not even sure I'll be able to overcome it but, I'm going to try. 

Display, or interaction? The last post was mainly on display (what the asm window shows).

Interaction, like adding special "stepping" or "skip one instruction" or .... that is a different story.

[Martin_fr]

Probably not needed for the asm related work, but that is the doc that currently exists on IDE internal debug structures: https://wiki.freepascal.org/TDebuggerIntf

[440bx]

Display, or interaction? The last post was mainly on display (what the asm window shows).

Interaction, like adding special "stepping" or "skip one instruction" or .... that is a different story.

Ideally both but, I can tell that it will be a while before I've gathered the necessary knowledge to do something useful (and correct <chuckle>.)

Thank you for all that info... that will help get my bearings.

[ccrause]

Well, I usually use Lazarus trunk, to debug FpDebug. (Mostly on Windows, but should be similar on Linux, if you take care not to freeze X-Server.)

One option out of this on Linux: drop to a text mode terminal (ctrl+alt+F1), find PID of lazarus instance(s) and kill:

Code: Bash  [Select][+][-]

1. $ pidof lazarus
2. 67557
3. $ kill -SIGKILL 67557

Then jump back to graphics (ctrl+alt+F7). The hotkey combination is dependent on local settings, so may be different, or disabled.

IDE-1 debugs IDE-2 debugs some test-project. => So the FpDebug in IDE-2 can be debugged from the IDE-1.

If I make changes that may be unsafe, then I keep a copy of the IDE's executable. I.e. I have a "lazarus.good.exe" in my lazarus folder, right next to the "lazarus.exe". They can both run in that folder.
If I start the debugger on "lazarus.lpi" it will start the "lazarus.exe".

Mind, that it can be helpful, to set "Run Params" to have a "--pcp=..." for the debugger IDE. Then the debugged IDE can start with different Window positions. (even be marked with  a different color scheme for the source editor (really prevents mistakes)).
But make sure to keep settings like "custom options" to build IDE unchanged. They affect packages too, and if they differ, the 2 IDE compete on recompiling everything.

Good advice! Alternative is to use gdb in IDE-1 to debug fpdebug in IDE-2.  GDB is a lot slower and not as convenient, but if you don't have a robust starting IDE, this may help.