compiler flags for release with debug symbols

[esatel]

I am building a python extension that has to be supported on python 2.7 with f2py using the intel fortran compiler 2013, the latest I can use and still get the compatibility I need with vs 2008.

My extension has a long history, but following a batch of changes now crashes python. I thought the first step would be to get some symbols or at least some line numbers and maybe check bounds. So I'm trying to create a "release with debug info" compile. However, when I recompile the static library with these changes, the bug goes away:

From: ifort /c /nologo /MD /Ifortran_include /O2 /debug:none

To: ifort /Zi /traceback /c /nologo /MD /Ifortran_include /O2

I realize my compiler is a bit dated, but it would still be valuable to know the standard way to generate symbols without perturbing code and I doubt that has changed. I wasn't sure whether the /debug:none needs to be preserved or how it plays with the /Z* options but in any event adding it doesn't change anything.

[Steve_Lionel]

My guess is that it's not necessarily that code has changed but that things have shifted about in memory. If you generate a link map for both versions you can compare them to see what, if anything, changed.

When you say /Zi, you are telling the compiler to put debug info in a separate .pdb file rather than in the object file.  If I am reading the documentation correctly, /Zi implies /debug:full. /traceback also adds data to the executable - what happens if you leave that off?

[esatel]

You were right that /traceback was the culprit altering the executable. When I remove that I get the crash again.

Is there an easy way to tell I have succeeded in getting symbols into the static library? Once I know that I have succeeded at that my issue becomes more of a python extension problem and less of an Intel Fortran problem 

I was hoping the symbols would be in the object file and ultimately passed to the static library and from there linked into the python DLL (pyd file). The documentation I read for /Zi said "produce symbolic debug information in object file" . Do I have it wrong? Do I have to specify /nopdbfile?

Also I didn't see where it said /Zi implied /debug:full though of course I believe this is true Do I need to specify /debug:none?  Does /debug:none imply a larger process of checks, memory protection and de-tuning of the optimization or is it just symbols and possible rejiggering the memory?

Thanks -- very helpful as usual.

[Steve_Lionel]

/Zi and /Z7 are inherited from Microsoft. As such, there are subtle interactions with other things. I agree that the Intel documentation here is unclear.

As I understand it: /Zi enables debugging, disables optimization (unless overridden, which you do), and puts symbol info in a PDB file. It sounds as if you want /Z7 instead to put the debug symbols in the object file.

If you also say /debug:none, you'll get no symbols. /debug does not turn on any checks - maybe you're thinking of /dbglibs.

[esatel]

I have changed to /Z7 and removed /debug:none. If this is a legacy item and there is a preferred way I'd love to know. I'm not trying to do anything oddball and I hear you about interactions.

The other thing that is pretty important is ... how do I determine success? How do I know that the symbols are in the static library? The reason I ask is that even with these changes it appears I am not getting any debug symbols in the python environment. I need to know whether I have the symbols in the static library to determine if this is an Intel Fortran issue or a python extension issue. 

Thanks again.

[Steve_Lionel]

There isn't another way to do this.

As for how to tell if the symbols are in the object - I don't know of a surefire way. If you do a "dumpbin" on the .obj it will give you the size of the .debug$S and .debug$T image sections. From my experiments, the .debug$T section is where the symbols reside as it is smaller if I use /Zi. Also, I can check to see if a .pdb file was created. The .obj is definitely smaller with /Zi.