Forum > Debugger

Debugging Lazarus/FpDebug

(1/2) > >>


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.

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?

There isn't a internal documentation on FpDebug.

Depending what you look to understand:

- Windows API

- man ptrace


- The involved file formats
pe and/or elf

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.)

--- Quote from: Martin_fr on January 28, 2024, 12:32:07 am ---Out of curiosity, what to you try to find by this debugging?

--- End quote ---

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.

Then your point of entry will be

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....


[0] Message Index

[#] Next page

Go to full version