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.
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?
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.
/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.
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.
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.