| I don't know the answer for sure, but I would start looking at the format
of the procedure frame pointed at by the frame pointer. These are all linked
together so you follow back through to the main program. I just don't know
if the actual name is stored in there. I suspect maybe not, since the debugger
has to load some information (set module) in order to get the routine names.
Burns
|
| You get the PC's by following the chain of call frames back.
And, no, the symbolic names are not stored there.
To get these, you have to read the DEBUG symbol table
information.
|
| Re: .1 & .2
The information I need seems to be included by the linker if the /TRACEBACK
qualifier is enabled. I can get it to the screen by calling LIB$SIGNAL(40).
It doesn't matter if it is linked with DEBUG or not. I had previously chained
back through the call frame and got the PC but couldn't find any pointers to
the other TRACEBACK information.
Is there an offset from something in the call frame that points to the Module
name, routine name, and source line number?
John
|
| No, this information IS NOT stored in the call frame, since that would slow
down most applications, even those that don't need tracebacks (like DIRECTORY,
or SHOW or your favorite compiler).
If traceback information is available (and/or enabled) in your image,
the image activator calls a system routine that remembers how to find
the image file (and hence the traceback information) when it's needed;
I believe it does this by hanging onto the channel number to the image.
It also establishes a condition handler on the stack.
When this condition handler is invoked (by standard means of invoking
a condition handler) for a W, E, or F-level signal, it maps the traceback
facility into memory, and calls it. The traceback facility reads the
traceback information from the image file to produce the traceback display,
which is written to SYS$OUTPUT. The traceback information can be used to
re-symbolize some of the PCs that are found when trapsing back through the
stack frames.
The interface to the traceback facility is undocumented, as is the format
of the traceback information, and the debugger information. The format
of an executable image is only modestly described in the VAX/VMS Internals
and Data Structures manual. With patience and some guesswork and a copy
of STARLET and LIB (the VMS fiche would help, too), you should be able to
get what you want to work (at least until the next major release of VMS,
since this stuff *has* changed before, and may change again).
If this were easy, or particularly useful, someone would've done it already.
Why are you interested in producing a re-symbolization of the traceback?
The traceback provided by VMS is useful, and a link map can also be a great
help in tracking down any problems in programs that are linked sans Debug.
Also, you could link the program *with* Debug, and use a hack program to
zap the image header so it looks like it's NoDebug. The information will
still be in the image file (if you need it), but the image won't start up
in the Debugger.
I hope this information helps direct your efforts to worthwhile persuits.
- Gilbert
|