[Lazarus] Making fpdebug more cross-platform friendly

[Martin Frb]

On 16/12/2021 12:10, Christo Crause via lazarus wrote:
>   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.
The current Frame-analysis is not really in good shape.

It is more likely that the central entry point for hardware and/or OS 
specifics will be the subclassed TDbgProcess (or potentially in some 
cases the subclassed Thread, but I can't think of a case for that....).
The process class can then decide to use the asm class, or have other 
means...

Dividing this between hardware and OS will be a story of its own.

>
> 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.
So that needs to be controlled by the process class then.


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

Probably there will be some need for delegate classes....

Btw, this is a big one, and I have some todo on this too.
Currently the entire handling of win SEH is in LazDebuggerFp => that 
should move. But it needs exactly the above ability of having target 
specific functions.
Even one step further: => those are not even default for win, because 
they assume fpc generated code [1]. So they need to be added, similar 
like the fpc additions for dwarf (separate unit, with detection of 
compiler....)

So it's likely they will undergo a big rework.

[1] They should be fixed to be generic.

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

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

The above will probably best go into a delegation class. But the extend 
needs to be evaluated.
The first 2 actually should allow to override (so that is not the 
desired solution)...

> 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.
As I said, there will have to be a big rework.
Until then, quickfix it by overriding it in the backend (like 
LazDebuggerFp does).


More later....