Offload debugging on windows

[PKM]

Hi

Having upgraded from parallel studio 2013 to the latest version of 2015 I am no longer able to debug MIC offload regions in Visual studio 2012. After the upgrade of parallel studio and the MPSS  I followed these instructions (https://software.intel.com/sites/default/files/article/391314/programming-phi-windows-1.7.pdf) to enable debugging, but I have been unable to get it working even for the LEO example described in the guide. On entering the first offload region with a breakpoint I simply get the message "Code not running - the current thread is not currently running code or the call stack could not be obtained".

Any suggestions?

C

[PKM]

I am not even getting any useful information from the offload regions in the traceback information provided when the code crashes when called from the command line:

Image              PC                Routine            Line        Source

LIBOFFLOAD.DLL     000007FEE514C926  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE513DA94  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE513D438  Unknown               Unknown  Unknown
LIBOFFLOAD.DLL     000007FEE5160FAE  Unknown               Unknown  Unknown
AarhusInv_intel_2  000000013FFB63AB  MCALCFIELDS_mp_FO         641  calcfields.f

compile line in Visual studio:

/nologo /debug:full /Od /heap-arrays0 /fpp /I"Debug/" /Qoffload:optional /Qopenmp /warn:noalignments /fpe:0 /module:"IntelFortran\Win64\Debug/" /object:"IntelFortran\Win64\Debug/" /Fd"IntelFortran\Win64\Debug\vc110.pdb" /traceback /check:all /libs:static /threads /dbglibs /Qmkl:parallel /c /Zi

Link line in visual studio:

/OUT:"IntelFortran\Win64\Debug\AarhusInv_intel_2013.exe" /VERSION:2.1 /INCREMENTAL:NO /NOLOGO /qoffload-ldopts="-lifcoremt -mkl=parallel" /MANIFEST /MANIFESTFILE:"IntelFortran\Win64\Debug\AarhusInv_intel_2013.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"IntelFortran\Win64\Debug\AarhusInv_intel_2013.pdb" /MAP /MAPINFO:EXPORTS /ASSEMBLYDEBUG /SUBSYSTEM:CONSOLE /HEAP:1000000 /STACK:50000000,1000000 /IMPLIB:"P:\casper.kirkegaard\ftn\aarhusinv_phi\IntelFortran\Win64\Debug\AarhusInv_intel_2013.lib"

Any suggestions will be greatly appreciated ...

C

[Kevin_D_Intel]

Sorry for the delayed response. I will check whether I can debug a Fortran offload sample under the VS 2013 and IPS XE 2015 release.

[PKM]

Reinstalling the MIC debugger extensions finally made it work ...

[Kevin_D_Intel]

Thank you for the update on the root cause and solution. Yours is the first that I had heard of that particular error and I had not been able to reproduce anything similar on my end, so I’m glad you resolved this.

You wrote "Reinstalling" but can I just confirm that you did install the MIC debugger extensions with the initial IPS XE 2015 installation and to resolve this issue you un-installed and re-installed just the debug extensions component?

I apologize, the document you referred to is dated related to the putty setup which is no longer necessary so I'll have the document updated. You could undo any putty setup you followed to avoid unneeded pollution of the MPSS area.

[PKM]

Yes, that is exactly what I did - ie. "install the MIC debugger extensions with the initial IPS XE 2015 installation and to resolve this issue you un-installed and re-installed just the debug extensions component" ...

However, now that I got it working I find that debugging offload code has become even more involved in the 2015 release. With the 2013 compiler any runtime error produced on the MIC side would typically give some kind of error message either directly in the debugger, or at least when run from the host command line. The messages would sometimes be hard to interpret, but at least you were given a hint. With v2015 I typically get no help at all as to what is happening on the MIC side - the traceback information I provided earlier is all I get. This means that I am left to find both the location and type of error myself, which makes debugging considerably more time consuming. I have both runtime error checking and traceback information enabled, but maybe I need some special switches to enable this on the MIC side in 2015?

Thanks!

C

[Kevin_D_Intel]

I am not aware of anything new or specifically needed for debugging offload code with IPS XE 2015 so I will inquire with others about your observations.

The article on Debugging Intel® Xeon Phi™ Applications on Windows* Host discusses basic requirements and usage; however, even if you have not seen it, I expect you are probably already following the recommendations it contains.

[Kevin_D_Intel]

Unfortunately I am not finding much.

I do not believe this impacts your case but there is a fix (associated with internal tracking id DPD200180997) in the 2015 release that resolves a defect (in the previous 2013 SP1 release) with not providing complete traceback information when using /check:bounds /traceback. In this specific case the program displayed the Fortran RTL (forrtrl:) error; however, no traceback was provided at all.

Our Debugger team is not aware of any improvements at the debugger level in the 2015 release. They indicate the debugger “just stupidly” forwards anything that pops up underneath so if errors are not forwarded anymore then it will not show anything in the output or dialogs.

Besides the traceback you noted in your earlier post, is there any information in the IDE “Output Window” when running under the debugger?

I do not know whether setting the environment variable OFFLOAD_REPORT=3 will shed any light on what stage the failed offload is reaching in your app, but you could try setting this when running via the command-line.

Something else you can try is the coitrace utility. This is an internal diagnostic Developer's tool that sometimes is helpful when used with the OFFLOAD_REPORT set simultaneously to observe the offload RTL’s interaction with COI. So you could try setting OFFLOAD_REPORT=3 and then running the app under the command-prompt as follows:   coitrace -short <your exe here>

If you can capture the output to a file that might offer us something to help determine the failure your program experienced.