Hi all,

Last weekend I started on the ability to evaluate functions within fpDebug. And I got quite far. It is a proof-of-concept, still needs a lot of work. But it works!

See it in action here:

http://amira.cnoc.nl/fpc/FpDebugCallProofOfconcept.gif

Regards,

Joost.

Great news! I guess this is a step towards evaluating object properties via get methods?

Joost van der Sluis schrieb am Di., 7. Juli 2020, 11:17:

Very nice! Looking forward to further improvements here. :)

By the way: how do you use it from within VS Code? Is that some generic debug interface?

Regards,
Sven

Op 07-07-2020 om 12:41 schreef Christo Crause via fpc-pascal:

That is the final goal, yes.

Regards,

Joost

Op 07-07-2020 om 14:17 schreef Sven Barth via fpc-pascal:

I am using this plugin: (Please install and give feedback) https://marketplace.visualstudio.com/items?itemName=CNOC.fpdebug

Well, actually I wrote it:
https://gitlab.freepascal.org/Joost/vscode-fpdebug

It's using Microsoft's debug-adapter-protocol (DAB), a generic protocol that can be used to glue editors and debuggers together: https://code.visualstudio.com/blogs/2018/08/07/debug-adapter-protocol-website/

I wrote a version of fpDebug that implements this protocol. In principle it should also work with other editors that implement this protocol: https://gitlab.freepascal.org/Joost/fpdserver

Regards,

Joost.

For this, we will need to start looking at improving the DWARF info. And most probably adding some vendor specific info.

Afaik, even Dwarf 5 does not supply those

We should probably start a wiki on this....

1) Encoding a property. This could be done by:
- Currently properties already point to the Field.   That could in future be: point to either the field or the getter. => Thus any debugger could read the info.
  The type of the property might point to a function declaration (for other debuggers)

- Adding a DW_AT_fpc_type_property attribute to the type, so FpDebug knows it is a property
  This would be added to DW_Tag_Member  Or for global properties to DW_Tag_Variable.
  => FpDebug would (in case of a function) show the property as the result type of the function.    (that does not apply for function refs)

- Adding a sub tag    DW_TAG_fpc_setter
  This contains the description of the setter/or the field   It could be left empty, if the outer TAG describes a field, and the setter is direct field access.

The absence of the DW_TAG_fpc_setter would mean a read-only property Alternatively the outer tag can have DW_AT_fpc_type_property_readable DW_AT_fpc_type_property_writeable

2) Extra info for managed data (ansistring, dyn array, smart pointer) Managed data needs to be marked with DW_AT_fpc_managed Also maybe DW_AT_fpc_managed_copy_on_write
- This would also make ansistrings distinguishable from pchar/array-of-char. Though for that ansistring could also have DW_AT_fpc_longstring.

There would also need to be info on
- initial default value: nil
- incref / decref
- alloc mem, for initializing/changing with a value that the user specified in the debugger
  Foo('abc') needs to create a string 'abc'.
  Modifying the value of an existing string, also needs this.

3) calling convention?
Not sure what information already exists.

----------------
Outside the scope of function calling:

- the dwarf info for nested procedures, and the outer variables that they can access, could be improved.
Currently there is some scope info lacking.

- Each unit should have a list of other units, in correct search order. So global symbols can be found according to pascal scope.

- file of text /file of record
I still haven't figured out what the dwar specs try to archive with their definition.
It defines a type, but there is no data to be viewed. Some users have pointed to what "stabs" did => exposing the internal filehandle, so one can see if the file is open. Not exactly "correct" but more useful than what dwarf offers.
I have no idea/preference what should happen on this. Just throwing it in.

Joost, it sounds like you have some VSCode extension experience but do you know anything about how to implement a language server extension? I've seen the official examples but they're based on the server itself being written in JavaScript and doesn't explain how a stdio server which is spawned in another process works (like the Pascal server, which is written in Pascal). I have very little JavaScript knowledge which doesn't help either. :)

Regards,
Ryan Joseph

Op 07-07-2020 om 16:25 schreef Martin Frb:

One step at a time. We'll come there.

Regards,

Joost.

Op 09-07-2020 om 05:29 schreef Ryan Joseph via fpc-pascal:

I had already planned to look at your language server. But now I'm working on the function-calling stuff first. Then a vacation. Maybe in August.

Regards,

Joost.