Step into subroutines using Intel GDB

[charlesgauthier1743]

Is there an existing issue for this?

• I have searched the existing issues

I have tried the Pre-Release of the extension.

• I have replicated the Issue in the latest Pre-Release

Description

I am trying to debug a very large legacy code base with mostly fortran77 code (with some f90 and C/C++).

It’s being run under linux wsl2. Compiler is Intel 2024, so it’s ifx for fortran.

Whenever I want to “step into” a subroutine, it won’t let me, it just steps over.

If i put a breakpoint in the subroutine, then it will stop there.

Intellisense works just fine. I can get the subroutine definition with a right-click.

Any idea what is wrong?

Screenshots

No response

Expected Behaviour

When you press F11, it should step into the subroutine, not step over it.

Version of Modern Fortran

v3.2.0

Version of Visual Studio Code

v1.100.2

Platform and Architecture

Linux WSL2

Additional Information

No response

[charlesgauthier1743]

Hmm, I have just realized that I can’t step into the subroutines with “gdb” itself either.

So, it has nothing to do with the “Modern Fortran” extension. My bad.

But, if I use the Intel debugger “gdb-oneapi”, then I can step into the subroutines.

Any advice on what i can do to make it work? Can you use “gdb-oneapi” with “Modern Fortran” extension?

[gnikit]

Can you use “gdb-oneapi” with “Modern Fortran” extension?

On Linux yes, on Windows I seem to recall that Intel did not ship GDB, but after looking at their website they now do.

Any advice on what i can do to make it work?

If your Intel env is initialised in you can point to a custom gdb location using miDebuggerPath

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "enter program name, for example ${workspaceFolder}/a.out",
            "miDebuggerPath": "/usr/bin/gdb",   // Make this point to your gdb executable
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "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
                }
            ]
        }

    ]

---

As to why the Intel GDB works and the GFortran one does not, it can be a lot of things. If the program is compiled with Intel compilers I wouldn't expect all its symbols to be readable via GFortran and vice-versa. My advice is use the debugger the compiler ships with for best results, else things can get messy.