DAP for Fortran object members (GDB)

[gnikit]

Hi All, I am one of the devs for the Modern Fortran extension and the accompanying language server fortls. I was wondering if you could shed some light with regards to your implementation of the Debug Adapter Protocol (DAP).

Because Fortran in UNIX platforms can use GDB for debugging (for both GCC and Intel compilers), I opted a few years ago to piggyback on your extension's implementation of DAP which has worked out amazingly well. The only small problem is that hovering over a member object while debugging in Fortran produces no output. The only way to navigate into the value of an object is by starting from the very top one

I suspect this has something to do with the fact that GDB output of Fortran objects and only Fortran objects use parentheses instead of curly braces (functions and subroutines seem to use curly braces like in C/C++)

Fortran (GDB)

$1 = ( b = ( a = ( var = 10 ), r = 0.100000001 ), dp = 0.20000000298023224 )

C++ (GDB)

$1 = {b = {a = {var = 10}, r = 0.100000001}, dp = 0.20000000000000001}

Strangely enough, Fortran arrays also use () notation and the C/C++ DAP seems to be handling them just fine.

Do you know what is going on? And more importantly, if the solution is something as trivial as parsing the GDB output with a different regex, would you consider adding that functionality to the extension (hidden behind a flag or something) so we could then set it in our launch.json?

As always, any and all help would be greatly appreciated.

---

P.S. hover and completion requests to our Language Server work as expected, so I don't think this is caused by using a different triggerCharacters when we register the completionProvider

Steps to replicate & MWE

module c_mod
   implicit none
   private
   public :: type_c, temp
   type, public :: type_a
      integer :: var = 10
   end type type_a
   type, public :: type_b
      type(type_a) :: a
      real :: r = 0.1
   end type type_b
   type, public :: type_c
      type(type_b) :: b
      double precision :: dp = 0.2
   end type type_c
   contains
   real function temp() result(val)
      val = 10.0
   end function temp
end module c_mod

program overloads
   use c_mod
   implicit none
   type(type_c) :: c; integer :: a(10) = 1
   print*, c%b%a%var
   print*, a
end program overloads

1. Install Modern Fortran
2. install fortls through pip (a prompt should pop-up)
3. Compile MWE via gfortran -g mwe.f90
4. Create a launch.json (the default one will do) using the name of your just compiled binary (by default it should be a.out)
5. Set breaking point in print*, c%... and launch the debugger.

[gnikit]

Hi guys, any thoughts on this? Any and all input would be appreciated.

[WardenGnaw]

The issue stems from the type information that GDB is returning to the debug adapter.

Hovering over:

Fortran

1: (9162826) ->1089^done,numchild="10",children=[child={name="var28.1",exp="1",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.2",exp="2",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.3",exp="3",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.4",exp="4",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.5",exp="5",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.6",exp="6",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.7",exp="7",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.8",exp="8",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.9",exp="9",numchild="0",value="1",type="integer(kind=4)"},child={name="var28.10",exp="10",numchild="0",value="1",type="integer(kind=4)"}],has_more="0"
1: (9162826) ->(gdb)
1: (9162826) 1089: elapsed time 2
1: (9166059) <-1090-var-create - * "a"
1: (9166059) ->1090^done,name="var29",numchild="10",value="[10]",type="integer(kind=4) (10)",has_more="0"
1: (9166059) ->(gdb)
1: (9166059) 1090: elapsed time 0
1: (9166068) <-1091-var-list-children --simple-values "var29" 0 1000
1: (9166069) ->1091^done,numchild="10",children=[child={name="var29.1",exp="1",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.2",exp="2",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.3",exp="3",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.4",exp="4",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.5",exp="5",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.6",exp="6",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.7",exp="7",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.8",exp="8",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.9",exp="9",numchild="0",value="1",type="integer(kind=4)"},child={name="var29.10",exp="10",numchild="0",value="1",type="integer(kind=4)"}],has_more="0"
1: (9166070) ->(gdb)
1: (9166070) 1091: elapsed time 1

C++:

1: (48959) <-1034-var-create - * "a"
1: (48960) ->1034^done,name="var5",numchild="1",value="{...}",type="A",thread-id="1",has_more="0"
1: (48960) ->(gdb)
1: (48960) 1034: elapsed time 1
1: (48973) <-1035-var-list-children --simple-values "var5" 0 1000
1: (48973) ->1035^done,numchild="1",children=[child={name="var5.private",exp="private",numchild="1",value="",thread-id="1"}],has_more="0"
1: (48973) ->(gdb)
1: (48973) 1035: elapsed time 0
1: (48974) <-1036-var-list-children --simple-values "var5.private" 0 1000
1: (48974) ->1036^done,numchild="1",children=[child={name="var5.private.var",exp="var",numchild="0",value="4195568",type="int",thread-id="1"}],has_more="0"
1: (48974) ->(gdb)

Within the locals window:

Fortran

1: (17057) Natvis failed to parse typename: Type type_b
    Type type_a
integer(kind=4) :: var
    End Type type_a :: a
real(kind=4) :: r
End Type type_b
1: (18179) <-1075-var-list-children --simple-values "var20.b.a" 0 1000
1: (18180) ->1075^done,numchild="1",children=[child={name="var20.b.a.var",exp="var",numchild="0",value="10",type="integer(kind=4)"}],has_more="0"
1: (18180) ->(gdb)
1: (18180) 1075: elapsed time 0
1: (18180) Natvis failed to parse typename: Type type_a
integer(kind=4) :: var
End Type type_a

C++

1: (48959) <-1034-var-create - * "a"
1: (48960) ->1034^done,name="var5",numchild="1",value="{...}",type="A",thread-id="1",has_more="0"
1: (48960) ->(gdb)
1: (48960) 1034: elapsed time 1
1: (48973) <-1035-var-list-children --simple-values "var5" 0 1000
1: (48973) ->1035^done,numchild="1",children=[child={name="var5.private",exp="private",numchild="1",value="",thread-id="1"}],has_more="0"
1: (48973) ->(gdb)
1: (48973) 1035: elapsed time 0
1: (48974) <-1036-var-list-children --simple-values "var5.private" 0 1000
1: (48974) ->1036^done,numchild="1",children=[child={name="var5.private.var",exp="var",numchild="0",value="4195568",type="int",thread-id="1"}],has_more="0"
1: (48974) ->(gdb)

In C++ it gives us the exact C++ class where during Fortran debugging it seems to provide definitions based on Fortran.

Here is a reference to where the debug adapter recieved the variable information from GDB and tries to visualize it https://github.com/microsoft/MIEngine/blob/8456c49b4731971b885c2909f9feaac4bdcd494d/src/MIDebugEngine/Natvis.Impl/Natvis.cs#L915-L947

As the debug type cppdbg is targeted for C/C++ source code, we are hesitant on adding flags for support for other languages. This is similar to experiences for Rust, Objective-C, ADA, and etc. Source level stepping works since this information comes from GDB, but the symbol and type information are different per language.

Ideally the debug type would be different (e.g. fortrandbg) and MIDebugEngine would load a different visualizer parser that supported Fortran types than the current existing C++ parser.

MIEngine is under the MIT License so your extension can build and ship a version targeted for Fortran.

[gnikit]

@WardenGnaw Thank you very much for taking the time to look into this. It is unfortunate that C/C++ and Fortran return so vastly different debug messages. I really was under the impression that the differences were minimal.

we are hesitant on adding flags for support for other languages

I wholeheartedly understand your reluctance to add features that are not meant to be used by your extension. I simply had to ask in case the vscode-cpptools team felt like adding (experimental) Fortran support.

Ideally the debug type would be different (e.g. fortrandbg) and MIDebugEngine would load a different visualizer parser that supported Fortran types than the current existing C++ parser.

So given that I have practically no knowledge on how to create a "debug type" would it be at all possible to point me to towards some example code/documentation to get me started?
Also, currently Fortran does not have an explicit DAP implementation, would creating fortandbg also involve implementing a DAP interface?

I have a very loose understanding on how the debugging feature works in VS Code, but from what I can tell it should be something like this:
Debugger -> MIDebugEngine -> OpenDebugAD7 -> DAP -> VS Code

Again, thanks for all the help and all your work in vscode-cpptools!

[WardenGnaw]

In the VS Code Extension side, you will need to register a vscode.DebugAdapterDescriptorFactory
See ours at

vscode-cpptools/Extension/src/Debugger/debugAdapterDescriptorFactory.ts

Lines 28 to 40 in 7fdddf2

	export class CppdbgDebugAdapterDescriptorFactory extends AbstractDebugAdapterDescriptorFactory {
	constructor(context: vscode.ExtensionContext) {
	super(context);
	}
	async createDebugAdapterDescriptor(session: vscode.DebugSession, executable?: vscode.DebugAdapterExecutable): Promise<vscode.DebugAdapterDescriptor> {
	const adapter: string = "./debugAdapters/bin/OpenDebugAD7" + (os.platform() === 'win32' ? ".exe" : "");
	const command: string = path.join(this.context.extensionPath, adapter);
	return new vscode.DebugAdapterExecutable(command, []);
	}
	}

and then register it to VS Code via registerDebugAdapterDescriptorFactory with the debug name.

vscode-cpptools/Extension/src/Debugger/extension.ts

Line 56 in f809a81

disposables.push(vscode.debug.registerDebugAdapterDescriptorFactory(DebuggerType.cppdbg, new CppdbgDebugAdapterDescriptorFactory(context)));

I have a very loose understanding on how the debugging feature works in VS Code, but from what I can tell it should be something like this:
Debugger -> MIDebugEngine -> OpenDebugAD7 -> DAP -> VS Code

That is correct (arrows actually point both ways there are Requests, Responses, and Events.

  graph LR;
      VSCode --> |DAP| OpenDebugAD7
      OpenDebugAD7-->|AD7| MIDebugEngine
      MIDebugEngine-->|GDB-MI| GDB

Loading

Here are some getting started docs: https://github.com/microsoft/MIEngine/wiki/Building-MIEngine-for-VSCode

[gnikit]

@WardenGnaw Thanks a lot for the help

[GitMensch]

MIEngine is under the MIT License so your extension can build and ship a version targeted for Fortran.

... or, as you don't want to use the rest of cpptools here (only the debugger) you may also try a different one that does not target C/C++ but GDB: https://github.com/WebFreak001/code-debug.

Note: if your language server did not included it before, consider to register an EvaluatableExpressionProvider - allowing to split (or combine) by Fortran specific expressions. Background: The vscode debug browser ui used to split words by the following:

		// Match any character except a set of characters which often break interesting sub-expressions
		let expression: RegExp = /([^()\[\]{}<>\s+\-/%~#^;=|,`!]|\->)+/g;

and that may not match Fortran best. For more details see Debug hover API, which allows you to say about what expressions are seen under your cursor.

[gnikit]

Thanks @GitMensch for pointing this out to me, and apologies for the delayed response. I was completely unaware of code-debug. However, I think getting code-debug to work for Fortran might be a bit more work than I can currently handle. It still looks like a very interesting project though.

As for the EvaluatableExpressionProvider this might actually be what I am looking for.

[gnikit]

@GitMensch You are an absolute life saver. I figured out what is going on. For GDB to yield symbols one must provide the entire object
e.g. c%b%a, which means that the regex must also much % not just the text in between.
Coming up with the regex that's gonna be slightly tricky, but at least I now know how the solution looks like.

@WardenGnaw Thanks again for the thorough explanation. One day Modern Fortran will have to create its own Debug Adapter, but that day is not today!

[GitMensch]

Is the symbol provider you use already aware of this, so "go to definition" goes to the correct place? In this case it would be possible to add the EvaluatableExpressionProvider to whatever extension provides your symbol quite easily.

[gregg-miskelly]

@gnikit To clarify your question, is this only about hover? In other words, if you type in the expression you are trying to hover over (I think c%b%a%var in your example, though maybe I don't understand since I have never programmed in FORTRAN before) into the watch window, do you get what you want?

If yes, then @GitMensch's reply from yesterday is the answer.

[gnikit]

Thanks for the comment @gregg-miskelly. Yes this is solely about hovering whilst debugging. I think you and @GitMensch might be right in that I have to register a EvaluatableExpressionProvider.

If that is okay with everyone I will leave this discussion open, until I find some time to implement and report back the changes.

Thanks again for all the help!

[GitMensch]

What I still miss (I gave it a quick try but totally failed): a simple extension that only registers an EvaluatableExpressionProvider for langIds from its extension setting, that only uses the document itself like in the mock sample to return words (=automatically uses the word definition from the langId) and ideally also checking its type this way to not return reserved words / comments.
So If you could hack that or at least preserve and reference a first commit that uses the document before using the language server this would be very useful!