Seems like the first message did not make it to the list. Maybe because
of the attachments... Retry:
Op 19-05-2020 om 16:42 schreef Martin Frb:
On 19/05/2020 15:55, Joost van der Sluis wrote:
It is not documented, and, to be honest, only name, value and type are
being used now. It is just a rough idea, we have to figure things out.
Ah, I see.
About DebuggerIntf:
1) DebuggerIntf was meant to be the API between IDE and the
debugger-backend.
The backend is TFpDebugDebugger.
FpDebug is not the backend, its used by the backend. But it currently
provides for the backend, and that means it uses those classes....
I was very disappointed when i (re?)-discovered that fpDebug has a
dependency on DebuggerIntf.
2) DebuggerIntf was never "designed".
It was ripped out of GDBMIDebugger, with the hope to be cleaned up and
refactored. That hope is still there....
That also raises the question what you base your DAB classes on.
Some code that you will need, does live in TFpDebugDebugger
- Detecting the instantiated class, instead of the declared class.
- Checking breakpoint conditions (Though part of this should move into
FpDebug)
- Handling Exceptions / stepping to except,finally (not sure if that is
likely to move)
It is even more complex then I could remember.
Thanks for the update, very useful. I think it is difficult to
discuss a new design/solution at a distance. I've tried to catch the
problems in some pictures.
Picture1: http://amira.cnoc.nl/fpc/FPDebugDesign1.svg
Picture1 show what I want to achieve. I want to use the formatting of
variables and such in another environment as Lazarus. And ind the long
term I want to make it possible for Lazarus to use other debuggers.
Also for other languages. (Using DAB or others)
Picture2: http://amira.cnoc.nl/fpc/FPDebugDesign2.svg
Picture2 shows the current situation at a high abstraction level. The
logic for displaying variables is all over the place, as you explained.
Please correct me, if I'm wrong somewhere.
Picture3: http://amira.cnoc.nl/fpc/FPDebugDesign3.svg
Picture3 shows a possible solution. We add a new class, in the picture
called 'formatter' to handle the display of variables. As an input it
will need some 'handler' which implements an interface with functions to
retrieve debug-information and access memory. It's output can be in
something like the TDbgVariable format I showed before. (Needs
adaptation, though).
In the picture I let the IDE make a direct connection to this new
'formatter'. But maybe it is better to do this in DebuggerIntf.
I also thought about a migration-path: we can just add this new route,
without using it. And then enable it bit-by-bit. We could alse add a
'default' implementation in DebuggerIntf. So all debug-handlers may use
it, or add overrides to do it in a different way.
What do you think?
Regards,
Joost.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
