In some routines not all variables are visible.

[dbl]

I am using Intel Fortran compiler with totalview debugger 8.0.2-0 on Linux 86. My problem is I cant access some variables at some points. To explain the situation I will give an example.

Program A
...
Use test

ierr=0

Call B(ierr)

End program A
!-------------------------
Module test
Contains
Subroutine B (ierr)
...
ierr = 1
Write(*,*) ierr
End Subroutine B
End Module test

When pause the debugger in program A, I can see value of ierr. But when i step into subroutine B and pause there, I can't see the value of ierr. It shows me <Bad address: 0x00000000> either in stack frame window or the variable display window when it opens when I double click on the variable. Program executes and writes the correct value of ierr. Interesting thing is while it is paused in subroutine B, I can select the calling program A and can see the variable. So it seems like the memory location is not transferred correctly or not transfered at all. Maybe module related?

There are other issues, but it may be the same cause. What can be the problem? Thanks in advance.

[PeterT-RogueWave]

Hello,

I just tried your simple test case and had no problem seeing ierr in the main or test routine. So, what might be happening? My first thought is that maybe this case had been compiled with optimization, and that caused the parameter to get stuck in register or otherwise optimized away. But I couldn't prove that based on just this simple test case. Of course, you show a space where I assume some code had been removed, while I'm using a test case where the code is at the bare minimum needed to make a valid program. More complex code may behave differently under optimization.

The other thought that occurs is that you might be using a less that ideal version of the Intel compiler, and that in itself is producing bad debug information. If you can identify the version of the Intel compiler (usually an ifort -V should give you the details) I might be able to test against that version to give you a better idea if there might be known issues with that version.

There's really nothing here that might be module related. It is true that people sometimes have problems finding data from modules (you should always dive on the module itself, rather than trying to dive on a variable). Here, though, ierr is local to the main program, and is a passed variable to the subroutine, so modules are not interfering. At least in this case. I can't vouch for what you might be seeing in your real application.

Let me know the version of the compiler you are using and I'll see if it I can replicate your experiences.

[dbl]

I tried with Intel Fortran Compiler 9.0, 9.1, 10.1. All give the same result.

I am not using any optimization flag. Here is the whole compiler options that I am using. :

F90OPTS = -g -debug extended -fpe0 -check bounds -check format -DLINUX_INTEL

Thanks in Advance.

[PeterT-RogueWave]

It's the -debug extended option that is causing us grief. WIthout that option, ierr is found. With it, I get the same <bad address> you see. Either Intel is emitting bad debug information with -debug extended, or TotalView is not reacting correctly to the debug information given. We can investigate that, but you might want to pass this on to support. I can't guarantee that bugs reported in this forum will get addressed.

[dbl]

Thanks for the support. It is working without that option now . I will pass this to support as a bug. Thanks again.

[jdelsign]

You'll want to test this, but I believe that TotalView 8.3 and later does a much better job at handling the Intel "-debug extended" option. The reason is that "-debug extended" generates complex DWARF 3 constructs that were not supported in TotalView 8.0. But, that said, if you can live without the '-debug extended" option, that would be better, because the compiler generates simpler DWARF.

[Josh-TotalView-Tech]

It is worth noting that in most cases TotalView does not support any debugging option besides '-g'. What this basically means is that we only test TotalView with target executable's that are built '-g' and we do not usually take into account any compiler specific extensions to the debugging format. From a user perspective what this means is that using these options when using TotalView does not help with debugging and could result in unpredictable results because we have not confirmed the interoperability of TotalView and the compiler with the debug option.