[Lazarus] Making fpdebug more cross-platform friendly

Christo Crause christo.crause at gmail.com
Thu Dec 16 12:10:03 CET 2021

Currently there are a few instances where x86 specific assumptions/code are
used [1] in what I consider as the target agnostic level of fpdebug.  My
proposal is to move these instances to a hardware target specific unit so
that these target specific handling is clearly separated.  One location for
the target specific code is perhaps the fpdbgdisas* units, since it already
provides a number of hardware specific concepts such as identifying call &
return instructions and some stack frame analysis.  Adding for example
IsSoftwareBreakInstruction seems like a logical addition.

These changes are hindering some functionality on AVR and Xtensa targets,
e.g. some instructions are incorrectly disassembled because they start with
$CC, which is incorrectly  interpreted as a software break.  Also the
StepOut functionality currently assumes the x86 ABI to locate the return
address, which obviously fails for other targets.  While these methods
could in principle be hidden by new target specific overrides, it is not
aligned with proper OOP principles.  I will start with some concepts to
address these soon.

Similarly, but possibly a bit more tricky, is to separate the OS code from
the OS view of the hardware.  This would imply for example that the
register handling in fpdbglinuxclasses needs to be separated from the rest
of the code so that one could re-use the Linux layer, but swap out the
hardware specific layer x86_Linux.  Similarly for Windows, the
WOW64_CONTEXT could be part of an x86_Windows unit, so that it is possible
to also define and use _ARM64_NT_CONTEXT for Windows on ARM64.

Any thoughts, critique or suggestions are welcome.

Best wishes,

[1] Examples of x86 specific code not in a x86 specific unit
fpdbgclasses.pas: checking for int3 and its x86 encoding in TDbgProcess,
TDbgThread and TBreakLocationMap
fpdbgcontroller.pas: TDbgControllerCallRoutineCmd uses x86 call specific
encoding in InsertCallInstructionCode and RestoreInstructionPointer,
StoreRoutineResult using x86 register specific assumptions,
TDbgControllerStepOutCmd.SetReturnAdressBreakpoint assumes return address
is stored according to x86 stack frame layout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20211216/b8d5f5d1/attachment.html>

More information about the lazarus mailing list