topic Strange debug location in Intel® Fortran Compiler

Strange debug location

DavidWhite — Mon, 17 Oct 2011 01:08:32 GMT

While trying to debug my code, I stopped at the line
CARATIO=.FALSE.
On pressing F11, debugger attempts to debug a location that is not part of my code, and is not even a location on my system:
f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\gs_support.c
What's happening here?

Thanks

David

Strange debug location

jimdempseyatthecove — Mon, 17 Oct 2011 11:32:28 GMT

F11 is stepping into a C Runtime Library function which was built on someone else's system. The Debug information in the object file (within the library) is pointing to the path as used on the other system.

Either use F10 (i.e. do not step into)

Or, if you have the source to this library located elsewhere on your system, the debugger has a property sheet where you can specify alternate locations for program source files. (use this property to point to the location of your copy of this source file (gs_support.c)

Jim Dempsey

Strange debug location

DavidWhite — Mon, 17 Oct 2011 23:41:22 GMT

Jim,

how can I be stepping into a C Runtime Library on this simple assignment statement?

I am not including any C projects in my application, althoughI am using RealWin. I have all the source files, several are which areCfiles, but nothing with this name, and definetely not with anything on F:, which does not exist on my system.

It is a mystery where this link comes from.

Regards,

David

Strange debug location

jimdempseyatthecove — Tue, 18 Oct 2011 00:35:40 GMT

F: (and path) is that of the machine of the developer that produced the library function.
This could be someone from Microsoft, Intel, etc...
The library is loaded/linked because the file name appears with the debug information in your file.

If you can place a break point at this statement and then run to this statement without going to la la land, then run to break, open a dissassembly window, and step into (F11) with that window open until you see the next statement is a program transfer (branch, call, ret, jmp, ...). See if the transferwill beinto this library or out of your program.

If your statement has a goofy branch... then possibly your code got overwritten by something.

If nothing unusual appears...

Get pen and paper (or open newtext file in the IDE)
Do the F11 thing *** and write down where you are in the code, include the hex address. Doing copy and paste with the mouse works.

If youdiscover a ret instruction takesyou into thegoofy routine then this indicates that your code destroyed the return address on the stack.

This will be a good learning experience for you.
Reading dissassembly is not as hard as it looks.

Jim Dempsey