Calling routine

[Brooks_Van_Horn]

Is there anyway to find out just the routine that invoked you. In other words:

Sub A -> Sub B

can B find out that Sub A called it?  IBM mainframe using their Fortran G could do it but it took an assembly program to do it but it was not hard. Does ivf use a particular calling method and is there a register/accumulator that keeps the return address or is some part of the stack that has a pattern that can be searched?

I have a routine that is called by one of 15 different routines and I would really like to find out which one invokes it. I care not what other routines call that one.

Thanks,

Brooks

[DavidWhite]

TRACEBACKQQ can be used to generate a stack trace, but I don't know whether you can interrogate the output, or redirect it to a temporary file, which you could read back in.

[andrew_4619]

David White wrote:
TRACEBACKQQ can be used to generate a stack trace, but I don't know whether you can interrogate the output, or redirect it to a temporary file, which you could read back in.

I do this in my debug setup. Yes you have to set an environment variable for the output file:

retl4=setenvqq("FOR_DIAGNOSTIC_LOG_FILE=C:\path\tracebackqq.txt")

[Steve_Lionel]

You can't query TRACEBACKQQ - it sends its output to stderr, I think. It might also not be reliable if the code is optimized, with routines inlined. 

Of course, there is a return address saved in a register, but you'd be largely on your own to access it, and once you did, there is no standard place where routine names are kept. Some method similar to Andrew's, where you set a variable (maybe a module variable) at the start of each routine, could help. More complex methods involve keeping a running stack of entries and exits - I have seen that in some sources.

[andrew_4619]

Actually Steve if FOR_DIAGNOSTIC_LOG_FILE is set in the environment then that is where TRACEBACKQQ sends output. I only had this in debug. It was a routine that queried if there were any system errors and if so it recorded a traceback to aid location. 

[Steve_Lionel]

Ah, I forgot about that. Thanks.

[dboggs]

You didn't state whether this is information YOU need--say upon inquiry at a breakpoint, or whether the program needs it at runtime to give some appropriate message or take other action.

The simple brute force approach, if you can tolerate modifying the source code, is to simply add another argument to the call. Just before every call, add a line setting the argument to a coded number or text phrase. I use this (rather stupid but simple) approach frequently and find it very easy to do.

But I suppose you have a greater (sophisticated) need? 

[Brooks_Van_Horn]

The traceback I get doesn't give me anything useful, not even line numbers -- which I have turned on. I would like to know if ivf follows some internal Intel standard for entry and exit from a subroutine/function. Can we get Intel to release the code in TRACEBACKQQ? I would prefer to know the entry/exit code ivf creates.

Brooks

[Steve_Lionel]

The calling mechanism is Microsoft-standard. Intel could not just create their own here. TRACEBACKQQ uses the Windows API routines in imagehlp.dll to walk the stack, but the symbolic info is written to the executable in a private format. The main program needs to be compiled with Intel Fortran to get the traceback on an exception, but a TRACEBACKQQ call should still work.

I have seen in the past that some QuickWin programs don't properly show traceback info.

[cryptogram]

PC's are stack based, and so calling subroutines involves putting stuff on the stack.   The caller puts argument information and a return address on the stack.  The called routine uses the stack pointer to get at the arguments and eventually pops the argument infomation and return address off the stack. 

This is a reasonably efficient way to get the required information passed between a caller and a subroutine, but it doesn't provide easy access to the name of the caller.

[andrew_4619]

calling TRACEBACKQQ works for me in showing the call back to where I am and how I got there. But maybe it is a Quickwin problem Brooks has.