GDB does not step into subroutine (ifx)

[Cook__Gordon]

When debugging application compiled with ifx, GDB steps over subroutine calls when issued a "step" command. If the code is compiled with ifort, GDB correctly steps into subroutine calls.

ifx:

$ ifx --version
ifx (IFORT) 2022.1.0 20220316
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

$ ifx -g -O0 -c hello.f90 -o hello.o
$ ifx -g -O0 test.f90 -o test hello.o
$ gdb -ex 'break 2' -ex 'run' -ex 'step' ./test
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-16.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
Breakpoint 1 at 0x403cd2: file test.f90, line 2.
Starting program: /home/kenche03/code/test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, test () at test.f90:2
2       call print_hello
 hello from subroutine
3       print *,"finished test"

ifort:

$ ifort --version
ifort (IFORT) 2021.6.0 20220226
Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

$ ifort -g -O0 -c hello.f90 -o hello.o
$ ifort -g -O0 test.f90 -o test hello.o
$ gdb -ex 'break 2' -ex 'run' -ex 'step' ./test
GNU gdb (GDB) Red Hat Enterprise Linux 8.2-16.el8
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
Breakpoint 1 at 0x402d99: file test.f90, line 2.
Starting program: /home/kenche03/code/test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, test () at test.f90:2
2       call print_hello
print_hello () at hello.f90:2
2       print *,"hello from subroutine"

It's possible to eventually step into the subroutine with code compiled with ifx, e.g. with multiple "stepi" or "set step-mode on", but ideally a single "step" command would do it.

Source code:

$ cat test.f90 
program test
call print_hello
print *,"finished test"
end program test
$ cat hello.f90 
subroutine print_hello
print *,"hello from subroutine"
end subroutine print_hello

[Louise-Linaro]

Hi - 

Has there been any update on this issue?

[Ron_Green]

I had a quick look.

First, do not use 2022.x ifx.  it's buggy.

Next, ifx is not ifort.  The objects and inlining is different.

print_hello is an external procedure (old F77 style).  

with ifx, use the -flto to get the linker to pull in debug info for these externals.  You only need it on the final compile/link for test

ifx -g -O0 -what -V -o test test.f90 hello.o -flto
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1472.3
GNU ld version 2.40-14.fc39
rwgreen@orcsle153:~/quad/monday20240429$ gdb -ex 'break 2' -ex 'run' -ex 'step' ./test
GNU gdb (Fedora Linux) 14.2-1.fc39
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...
Breakpoint 1 at 0x4051d2: file test.f90, line 2.
Starting program: /nfs/pdx/disks/cts1/quad/rwgreen/monday20240429/test 

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, test () at test.f90:2
2	call print_hello
 hello from subroutine
3	print *,"finished test"

[Louise-Linaro]

Hi @Ron_Green 

Thanks for taking a look - however, looking at your code snippet, the step just stepped over the call to `print_hello` it didn't stop in it. 

It is on line 3 of test.f90 not on line 2 of hello.f90 as expected.

[Ron_Green · Accepted solution]

Ah, I see what you are looking for.  Perhaps there is something we can do to get the functionality you are seeking.  To make this example behave like ifort or gfortran.  I'll open a bug report and see what if anything we can do.  It takes cooperation between the debugger and the compiler binaries.  We hope the gdb developers test with ifx - but I rather doubt it.  It's hard enough to get gfortran support.  it could be that we had to enhance our object and debugger info to work with our GPU offload functionality in ifx.  If that is the case, then gdb will need a fix to work with our debug info.  But if it's our issue and we can fix it, we'll do that. 

 But I found a workaround for you

You can use gdb-oneapi.  it's Intel's enhanced gdb to work with our new binary formats needed for oneapi.  We have some extensions for Fortran as well.  It works with your example and ifx as you expect.

$ ifx -g -O0 -what -V -c hello.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1472.3

$ ifx -g -O0 -what -V -o test test.f90  hello.o
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1472.3
GNU ld version 2.40-14.fc39

$ gdb-oneapi -ex 'break 2' -ex 'run' -ex 'step' ./test
GNU gdb (Intel(R) Distribution for GDB* 2024.1.0) 14.1
Copyright (C) 2024 Free Software Foundation, Inc.; (C) 2024 Intel Corp.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.

For information about how to find Technical Support, Product Updates,
User Forums, FAQs, tips and tricks, and other support information, please visit:
<http://www.intel.com/software/products/support/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...
Breakpoint 1 at 0x4051d2: file test.f90, line 2.
Starting program: /nfs/pdx/disks/cts1/quad/rwgreen/monday20240429/test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, test () at test.f90:2
2	call print_hello
print_hello () at hello.f90:2
2	print *,"hello from subroutine"
(gdb) step
 hello from subroutine
3	end subroutine print_hello
(gdb) step
test () at test.f90:3
3	print *,"finished test"
(gdb) step
 finished test
4	end program test
(gdb) step
0x00000000004051ad in main ()
(gdb) quit
A debugging session is active.

	Inferior 1 [process 3844808] will be killed.

Quit anyway? (y or n) y

[Louise-Linaro]

Hi @Ron_Green 

Yes running under gdb-oneapi fixes the issue.

Is there plans to upstream the fix for this issue or do you know the patch that fixes it?

Thanks,

Louise