I feel like support for ifort-built Windows binaries debugging in vscode is long overdue.
I have tried to explain my reasons here in a sort of a plea to Intel to maybe get things going in the right direction:
Would be great if anyone who feels the same way could support the request by upvoting or commenting on the issue on the Intel forum so that it gains some traction.
Also, let me know what you think (preferrably on the Intel forum, though).
Thanks!
The post raises some interesting problems but I think there are solution for most of the problems mentioned, with an exception probably being ifort + Windows.
The “debug extension” is actually not a trivial task; not only do you need the VS Code extension but you also need to create an implementation of the Debug Adapter Protocol (DAP) for Fortran.
Currently how the debugger in VS Code works is that it piggybacks on the DAP servers from C++, which are proprietary, to provide debugging.
This works relatively well for the most part, but there are some issues with hovering over custom type variables e.g. some%foo%bar, hovering over foo will yield nothing
See my discussion with the vscode-cpptools team for more.
Points raised in the Intel post:
Arrays (one of the most important features of Fortran), however, cannot be viewed.
I am afraid I do not quite understand this one. Arrays can be visualised in both watch windows and hover just fine
allow breakpoints in .f90 files.
Also not sure about this one, these are the default extensions for Free Form Fortran and of course you can associate more from the settings
"extensions": [
".f90",
".F90",
".f95",
".F95",
".f03",
".F03",
".f08",
".F08",
".f18",
".F18",
".fpp",
".FPP",
".pf",
".PF"
],
My guess is that the debugger on Windows + ifort are not fully working. I recall an issue being raised by a user in the Modern Fortran repo, which was forwarded to the vscode-cpptools team.
So the issue boils down to the last comment by WardenGnaw
There are definitely features missing from Modern Fortran and fortls that would make our lives a lot easier if present, but at the end of the day it is a matter of available free time and resources.
@mkonecny , I have posted my support and comments at the Intel forum.
Chances are rather high that when it really comes down to it, you may find Intel Software management is uninterested in any allocating additional resources beyond that needed for the most rudimentary support toward maintaining the Intel Fortran integration with Visual Studio which is what has been the case for nearly a dozen years now. My management, for example, has noticed no improvement at all with Intel Fortran integration with Visual Studio IDE since 2008 and they are really angry and upset. On the other hand, the users often have to deal with painful regression as Microsoft issues new Visual Studio versions and features that worked before stop working and it takes years before something that worked in the debugger way back in 1998 starts to work again when reported to Intel support circa 2020.
Resources toward IFX compiler only might be the extent of Fortran support Intel is willing to expend. You know very well as a user that is wholly inadequate - one needs top-notch compiler, debugger and IDE/editor to be functional - but Intel management may not oblige.
Your company then needs to seriously make a “call” i.e., whether to continue to slog it out with Fortran or migrate away - a whole lot of industries including mine are fed up with the slow pace of everything in the Fortran ecosystem and moving away from Fortran entirely. And given with how good the other languages have become (especially C++20 and beyond for compiled library solutions e.g., DLLs on Windows) and especially how powerful their ecosystems have become and the pace at which they are evolving toward enhanced programmer experience and productivity but more importantly with program performance, know for sure Fortran is not missed a bit.
Is Intel GDB relevant?
But it seems support Visual Studio and not VS Code.
Yes, it absolutely is!
That is how you debug with ifort/ifx on Linux and Mac, you just point the debug adapter to the Intels GDB implementation instead of the default one.
It works for *nix binaries, but it doesn’t understand Win32 binaries. I guess the Windows GBD is only there for remote debugging or something… (I’ve tried fiddling with it, can’t remember the exact details at the moment)
AFAIK Intel’s GDB used to be only for Linux now that I checked again their website Windows is also listed so they might have fixed it.
Unfortunately, I lack a Windows machine with OneApi to test myself.
Thanks for your inputs. I was gone for a week so I couldn’t react as well as I would have wanted.
I am afraid I do not quite understand this one. Arrays can be visualised in both watch windows and hover just fine
All works for me on Linux as well. The problem is on Windows, where, even though there indeed is a windows binary of GDB distributed with ifort, it’s not suited to be used to debug windows binaries built by the windows ifort. Not sure what it’s for then, I had an idea a while ago when I played with it, but I forgot.
Thanks for linking the issue at vscode-cpptools. This discussion there only confirms, that it’s Intel who has to do the work to make the debugging available, apparently by shipping an Expression Evaluator.
For some reason I wasn’t using the Modern Fortran extension. I’ll give it a go 
. It indeed seems to enable breakpoints wherever I need.
@FortranFan :
Thanks for your support.
I realise the chances are slim, but the things I described above are such a pain for me (and my colleagues), that I decided it’s worth the time, even if I push them just a little bit.
Unfortunately, leaving Fortran is a no-go for us. We rely heavily on the speed it provides, it’s one of the main selling points of our products.
We also have to build for Windows, because that’s where our target market is.
But honestly, we don’t even really want to leave it. It’s not such a bad language, it just needs a bit of a revamp. Honestly, if I could just properly use a better IDE, I’d be happy.
I realise this might not be the highest priority for Intel. Depends what their priorities are. That’s why I tried to make the job for them as small as possible - just supply the debugger/Expression Evaluator. Everything else can be done (/already is done) by the community.
On the other hand, by doing a relatively small thing they could boost the usability of their solution on Windows be miles. So it should be a no-brainer 
.
Okay, there are still a couple of things I want to try, but I lack the time at the moment to see if I can get Intel compilers to work with GDB on Windows. Although, I wouldn’t be too optimistic about my ideas.
In general, I think we should collect our grievances and feature requests, not just with Intel, but with the general state of the Fortran tooling and see what we can implement to VS Code’s Modern Fortran. (I already have a fix with regards to debugging, that I am waiting to release, but I am being delayed by Microsoft’s slow replies).
@mkonecny , it’s good to read you and your company see continued value with your codebase in Fortran.
As to Intel, if you can procure paid support subscription and use that avenue to establish contact with personnel on the Intel SW side who have stewardship responsibilities for Intel Fortran or are inclined to see themselves as having such a role, you might find some success in your engagement.
Otherwise, the chances are rather high of either no positive movement by Intel SW side on this aspect or that you won’t hear anything for a while and boom, there will be an announcement of something that gets you excited, it has all the right verbiage and so forth, but when try it out you will find it has more holes than a horse trader’s mule. You will then wonder why they didn’t work with you the whole time.
Anyways, one can always hope past performance is no guarantee of a future result!
@FortranFan, is this based on personal experience, do you have any insight into Intel or why do you judge so?
@gnikit, the debugging issue isn’t related to Windows, though, is it?
I think I stopped trying to make GDB work when I realised MSVC and ifort store debugging symbols in a separate .pdb file whereas gcc stores them in the binary itself, AFAIK.
I figured GDB isn’t going to understand the .PDB format.
Happy that you are using Fortran for your SW products.
From your Github profile I can understand that you may be working on Finite Element Methods. Can you please tell me what products you exactly build. Just for curiosity sake…
@mkonecny I am not entirely sure. I can tell you what I suspect will work and I have been meaning to try.
Using in your launch.json
"type": "cppdbg""MiMode": "gdb""miDebuggerPath": "path\\to\\intel\\gdb.exe"My understanding is that cppvsdbg has the problem with Intel compilers and not cppdbg. Let me know how you get on
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/a.out",
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "path\\to\\intel\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
},
]
}Yes, what I have been feeding back to you and recommending to you and more importantly, where I am level setting your expectations is based on prior experience.
@mkonecny , how viable for your team is the workflow where the code development and debugging and thus the need for IDE with (preferably) graphical debugging is concentrated (perhaps even exclusively) on one platform? With well-designed codebase that is authored and maintained with discipline, in principle this is viable, especially with standard Fortran considering the portability it provides.
With standards-based well structured code that minimizes and isolates platform-specific dependencies, one can then target multiple platforms with the same codebase without having to do much additional development and debugging on the other platforms. Thus it appears conceivable one does development and almost the your domain/subject matter specific debugging on one platform, say Linux given you find it to work well for you, but then only needs the minimum needed to deliver support of one’s codebase on other platforms such as Windows, MacOS, etc.
So the question is how practical is this for your codebase? That might then free you up more from Windows and the problems you state you face on it.
This is not viable for us. Our user base is exclusively on Windows, so that’s what we have to build for.
We also build some things for linux for internal purposes, but I’ve found there to be subtle differences between Windows and linux compilers (even the exact same version of ifort).
So if I’m debugging anything, I still need to debug it on the same OS as the customer has, so it makes little sense to maintain builds for multiple systems just for the sake of not having to use VS. (There would be other drawbacks, so little benefit overall.)
It’s interesting to me personally a renewed search for Visual Studio Code of late on a personal device led to the following link from Microsoft getting highlighted for me with the use of Outlook in Edge (it suggests again the refrain: the digital trail of bread crumbs one inevitably leaves behind online gets picked up by someone or other, especially the big players):
Getting started with Rust in VS Code
Nonetheless, that brings up a question: when, if ever, will there be a livestream online called “Getting started with Fortran in VS Code” that covers, “Come learn how to get started with programming in Fortran in Visual Studio Code and set up your development environment. We’ll cover setting up the Fortran-analyzer extension, using code completion to write code faster, how to refactor Fortran code, running tests, and debugging .”?
I think we were planning on doing something like this once I finalised the VS Code extension update and transfer to fortran-lang (which is what I am doing currently at 2:00am). Tbh, the main problem is the very little free time I have currently.
On the plus side, the GitHub repo has already been transferred to Fortran-lang, so hopefully by the end of the summer we should have made a Getting started for both users and the VS Code extension devs.
Potentially for the users, a Walkthrough could be written thus eliminating the need for a video.