warning LNK4209: debugging information corrupt; recompile module; linking object as if no debug info

[OSD]

I am getting the following warning when creating a 64-bit Debug build:

SYNOPSYS_lib_.lib(<filename>.obj) : warning LNK4209: debugging information corrupt; recompile module; linking object as if no debug info

I see this warning for 26 of the 1000+ Fortran files that we have in our app.

I figured out that the “ENTRY” lines in the Fortran files are causing the warning.  These files all have ENTRY lines in the file's subroutine.

Background:

The app is mixed language:  C++ (Visual C++/MFC) and Fortran.

Each Fortran subroutine is in its own file.

We are developing in Visual Studio 2017.

We are using Intel® Fortran Compiler Classic 2021.2.0

We also have Intel 2011 Compiler installed for original/previous development.

We originally had a 32-bit app.

I converted it to a 64-bit app:

1. Created a new C++ (Visual C++/MFC) 64-bit project in Visual Studio 2017, then added the needed C++ files.
2. Created a new Fortran 64-bit project in Visual Studio 2017, then added the needed Fortran files

The app builds and runs as a Debug or Release build.

Let me know what properties, settings, and files that you need from me.

Thanks,

Preston

OSD

[mecej4]

You can use the command

     dumpbin /sections <name>.obj

on the suspect obj files. Take one of those 26 files (one for each letter of the English alphabet!), compile that file using the command

     ifort /debug /Od /c <suspect>.f90

and probe the resulting .obj file with the command

     dumpbin /sections <suspect>.obj

If you see in the resulting output some lines similar to 

Summary

260 .debug$S
30 .debug$T
BB .drectve
C .pdata
20 .text
48 .trace
8 .xdata

the file does contain debug information. Whether that debug information is correct or corrupt is, of course, another matter.

If possible, provide one of the problematic subroutine source code, and a short driver program to enable the bug (if present) to be reproduced and examined.

[OSD]

Thanks.

I'll go through the files that have the problem, and see if I can find one suitable to upload.

In the meantime I'll try the above commands to see what is produced.

In case it makes a difference, we are maintaining the (original) F77 syntax, and the files all have the ".for" extension.

Preston

Developer

OSD

[mecej4]

I rarely use Visual Studio and the Fortran codes that I work with, even the very old ones from Netlib and elsewhere dating back to the 70's, rarely contain ENTRY statements. I wrote a short test code to see how IFX (Version 2024.0.2 Build 20231213) fares when debugging Fortran sources with ENTRY present. 

The main program:

program tsub
   integer a1, a2, a3, a4
   a1 = 11
   a2 = 12
   call sub(a1,a2,a3,a4)
   print *,a3,a4
   call sube1(a1,a2)
   print *,a1,a2
end program tsub

and the subroutine with an additional ENTRY:

subroutine sub(a1,a2,a3,a4)
   implicit none
   integer a1, a2
   integer a3, a4
   integer p, q
   a3 = a1 + a2
   a4 = a1 - a2
   return

   entry sube1(p,q)
   p = p+q
   q = p-2*q
   return
end subroutine

Compile and link with

ifx /MD /Zi tsub.f90 sube.f90

and run the resulting EXE in the VS debugger (I used VS2019 Community on W11). Step through the program, and note how (1) the current line indicator (right-pointing thick arrow with borders) jumps around as you step through the statements, including going to lines where it has no business going, and (2) how poorly the display of the variables in the Locals pane is updated. 

The situation is just as bad with the last version of the IFort compiler.

After some people have had time to test this code out, if needed I can give a lengthy description of the reasons why, in my opinion, code with ENTRY, which was declared "obsolescent" many years ago, cannot be debugged using the combination of Intel Fortran compilers with Visual Studio. My guess is that the debug information on code address (%RIP) in the OBJ files is poorly correlated with the line numbers in the source, and that this defect also affects the VS debugger's notion of whether a source variable is  in scope on the current source line.

Please note that the short test code does contain ENTRY, the compiler does generate debug information and the linker has no complaints regarding debug symbols in the OBJ files. The problem is that the debugging support is inadequate in many ways.

[OSD]

Thanks again.

In one file I couldn't even step into the subroutine.

The debugger stepped over the call to the subroutine when I tried to step into it.

Preston

Developer

OSD

[OSD]

I placed the above example code into a file called "SUB.for", added this file to our Solution, and implemented the following call to the new subroutine:

IA3 = 0
IA4 = 0

CALL sub( 1, 2, IA3, IA4 )

Note:  We use the following IMPLICIT statement in our files, so the above variables are implicitly INTEGER's:

IMPLICIT DOUBLE PRECISION (A-H,O-Z)

After cleaning and building the application as a Debug build, I see the following:

library name.lib(SUB.obj) : warning LNK4209: debugging information corrupt; recompile module; linking object as if no debug info

Following the above exercise:

1.  dumpbin /sections SUB.OBJ (using the file built when compiled in Visual Studio)

Summary

        534 .debug$S
        84 .debug$T
        114 .drectve
        18 .pdata
        38 .rdata
        17C .text
        A0 .trace
        18 .xdata

2.  ifort /debug /Od /c SUB.for

3.  dumpbin /sections SUB.OBJ (using the output file from step 2)

Summary

        34C .debug$S
        100 .debug$T
        B9 .drectve
        18 .pdata
        C8 .text
        18 .xdata

Verifying that the OBJ file contains debug information.