Not able to debug in to Fortran Static library code

[Narenu]

My environment: VS2013 and Intel Visual Fortran Composer XE 2013 SP1
I've a C++ project, which calls the functions in statically linked Fortran library. When I run the main program, it runs correctly. It calls the functions in Fortran and returns the value. But I could not debug into the Fortran static library code. I can step into the C++ code,but not inside the Fortran function.

The fortran static library project creates the PDB file, but the visual studio is not loading that PDB file. Could someone please let me know what I am missing here, and how to debug the static library project?

Here are my settings from Fortran project property page:

Configuration Properties
     -- Debugging
         Command -- $(TargetPath)
     -- Fortran
          General
          Debug Information Format  -- Full (/debug:full)
          Debugging
              Debug Information Format  -- Full (/debug:full)
              Information for PARAMETER Constants -- All (/debug-parameters:all)
         Output Files
             Program Database File Name -- MyProjectName.pdb
          Command Line -- /Debugging
     -- Librarian
          Output File -- MyProjectName.lib

[mecej4]

Do you use the Intel C compiler or the MS VC compiler? Can you show us the buildlog.htm file?

There should be two .PDB files, one called vcxxx.pdb from the Fortran compilation, and another created by the C compiler with a name that depends on how you built the EXE. For example, I did icl /Zi cmain.c fsub.obj at the command line, and the resulting PDB file was called cmain.pdb. At any rate, the messages issued by the linker are the ones where you would see problems with generation of the PDB files for use with the EXE.

[Narenu]

I use MS VC compiler. I've both PDB files in the same bin\debug directory. For Fortran, I changed the default name from vcxxx.pdb to my projectname.pdb file to match the output lib file name. So my Fortran output file names are MyProjectName.lib and MyProjectName.pdb.

In my C++ project, I am using Zi for Debug Information Format.

I can debug upto the C++ code where it calls the Fortran function. But it does not step in to the Fortran code. (even if I use F11 in VS).

The only way I can debug the Fortran code now is only by converting the static library to exe file. But other programs are linked to the static library, so I need to be able to debug the lib file.

[mecej4]

The loose usage of terminology causes me to doubt whether your description is misleading. You say

The only way I can debug the Fortran code now is only by converting the static library to exe file. But other programs are linked to the static library, so I need to be able to debug the lib file.

There is such thing as "debugging the library file". A library file is simply a collection of .OBJ files, perhaps augmented with a dictionary/directory to speed up linking of those OBJ files. OBJ files contain relocatable code, but also missing external symbols. Without further processing by the linker, the code in the OBJ file and, therefore, in the LIB file, is not executable. Symbolic debuggers do not work with LIB files or OBJ files.

Similarly, if you have two sets of OBJ files (in or out of a library file, location does not matter), one set with debug symbols and another without, you will be able to debug at the symbolic level only within the source codes corresponding to the first set. You can debug in assembler mode in members of the second set, but you may not wish to do this.

Do you have a build log that you can post?

[Narenu]

Thanks for your quick response, I really appreciate.

Please find the attached build log files from my Fortran and C++ projects.

I've the same Fortran code in two different projects. One project creates an exe file, that is used by our C++ Windows application. We also have this same Fortran code base in a Static library project. We ship this lib file with different set of programs. Those programs just link this static library. The issue I'm having is not able to debug the static library project.

[mecej4]

The Fortran build log looks fine, but the C++ log does not. There is no evidence that an EXE was built at all, and there are some unexpected messages about CLR assemblies.

Therefore, it is possible that, when you start debugging, you are starting an older EXE that was successfully built some time ago and is still present. That EXE may have been built with no debugging support present in the Fortran library code. I suggest that you do "Clean" in VS and rebuild and try. You can also locate and remove the old EXE using the Windows File Explorer, after noting the date on the file. If these steps fail, since I do not know how the files are laid out, I recommend that you create a new folder elsewhere on your system, copy all your source files there, and rebuild in the new location. If that works, you can delete the old project directory and adopt the new one as the working project directory.

The issue I'm having is not able to debug the static library project

There is no issue here. A static library project is "done" when the library is created. There is nothing to debug within the confines of such a project. You can debug an EXE or a DLL, and that EXE or DLL may contain code taken from the library, but you cannot debug a library by itself. (Well, theoretically one could write out the code on paper and by sheer application of logic find errors in the code, but that is not the process that one normally has in mind when one says "debug".)

[Narenu]

mecej4 wrote:

Quote:

The issue I'm having is not able to debug the static library project

There is no issue here. A static library project is "done" when the library is created. There is nothing to debug within the confines of such a project. You can debug an EXE or a DLL, and that EXE or DLL may contain code taken from the library, but you cannot debug a library by itself.

Thank you, this explains all. I shouldn't be trying to debug the lib file. I will convert the project to DLL and try to debug the code. Thanks again for all your inputs.

[IanH]

You cannot debug a DLL in isolation either - you will just have the same problem.  You need to be debugging a program that uses the library.

Sometimes it is useful for testing to have a simple wrapper program that calls the library in a controlled manner.

From the build log your "C++" code looks like it is managed .NET code.  Ensure you have "enable native debugging" selected in the project properties (debug section) for the C++ project.

[dboggs]

Not sure this is helpful, but here's my .o2 worth.

I use static libraries a lot. In the early stages my .lib files were composed of .obj's that were built in release mode. There were two problems: (1) when debugging a project that was linked to the lib, I was not able to trace execution into those obj's, set break points in them, watch variables, etc.; is this what you possibly mean by "debugging a lib code"? (2) the project built in debug mode did not ALWAYS work correctly with the lib obj file built in release mode. Usually yes, but not always, and it was very frustrating.

Since then I have taken to maintaining two copies of my libraries--one built in debug mode and one built in release mode. When developing a new project, the debug project build is linked with the debug library, and the release project build is linked with the release library. The intermittent problems no longer occur, and WHEN DEBUGGING I CAN NOW STEP INTO THE LIBRARY SUBROUTINES, SET BREAKPOINTS IN THEM, INQUIRE VARIABLE VALUES, ETC. This is not really "debugging the lib code," but rather, using the debugging tools inside the library code to help debug the calling application. And yet, it has occasionally revealed weaknesses in a library routine and allowed me to take corrective action.

I'm not sure this is what you are really talking about, but it was a revelation to me.

[Narenu]

dboggs wrote:

I use static libraries a lot. In the early stages my .lib files were composed of .obj's that were built in release mode. There were two problems: (1) when debugging a project that was linked to the lib, I was not able to trace execution into those obj's, set break points in them, watch variables, etc.; is this what you possibly mean by "debugging a lib code"?

Yes, this is exactly what I am trying to do. I need to be able to set a breakpoint and walk through the code to see what it does.

dboggs wrote:

WHEN DEBUGGING I CAN NOW STEP INTO THE LIBRARY SUBROUTINES, SET BREAKPOINTS IN THEM, INQUIRE VARIABLE VALUES, ETC.

In visual studio I do have two modes debug and release. But I could not step into the library subroutines even in debug mode. What did do you differently from release mode to step through the code. Please see my settings in first message.

[dboggs]

Well I haven't left a good trail of settings and their results, so will have to investigate some. It may take a few days--I'm only going by memory right now.

[Narenu]

ianh wrote:

From the build log your "C++" code looks like it is managed .NET code.  Ensure you have "enable native debugging" selected in the project properties (debug section) for the C++ project.

Yes, my C++ project is a managed code (clr wrapper to call the Fortran code).

Thank you for your suggestion. After I enabled the native debugging I am able to step inside the library code. I can add breakpoints and step through the code. But I am not able to see values in any of the variables. When I add watch to local/global variables I get the following error,

CXX0017: Error: symbol "variableName" not found

I saw some people on this forum had this issue, but none of them worked for me. Also, I don't see my lib file loaded in Debug-->Window-->Modules section. All the files are in the same directory (exe, lib and corresponding pdb files). Optimization is disabled in my C++ and Fortran project. Have anyone seen this error before?

[JVanB]

Regarding Quote #8: isn't there a difference between a DLL and a static LIB in that for a DLL you can add a subroutine that matches the required interface:

abstract interface
   subroutine EntryPoint(hwnd,hinst,lpszCmdLine,hCmdShow) bind(C)
      use IFWIN
      implicit none
!DEC$ ATTRIBUTES STDCALL:: EntryPoint
      integer(HANDLE), value :: hwnd
      integer(HANDLE), value :: hinst
      character lpszCmdLine(*)
      integer(SINT), value :: hCmdShow
   end subroutine
end interface

to the DLL and then invoke it via rundll32.exe so that you don't need another project to start stepping through the DLL.

[IanH]

I consider rundll32.exe to be "a program that uses the library".  It is generic in nature, but you could construct a similarly generic "linkandrundstaticlib32.exe", and this sort of approach is sometimes used to reference user subroutines from pre-compiled and linked software packages.

I haven't tried it, but you may be able to trick the OS image loader into using a DLL image as an EXE (I think the only material difference is a flag in the P.E. header).  But with this, and the above, I think we are going rather beyond the conceptual level relevant to this thread.

I am not particularly familiar with what happens in the managed programming context, but for a single executable module I would expect there to only be one relevant PDB file, generated by the linker when the executable module (EXE file in this case, DLL in others) is linked.  You will not have an entry in the modules section (i.e. executable modules such as DLL's or EXE's) for a static library, the code of the static library is part of the executable module that the static library has been linked into.  I wonder whether fiddling with options in order to find a solution to the original problem has broken what I would otherwise expect to work out-of-the-box.