Live debug stack trace on IA64 versus AXP

[Claus Olesen]

We build and run the different programs of our OpenVMS v8.2-1 based product using basically these commands
$ cc file /opt=noinline
$ link image
sys$creprc(...,image,...);

To get a stack trace of a (hung) process we live debug using these commands
$ debug/keep
connect
show calls

On AXP the above "show calls" command provides a stack trace that includes module names, routine names and line numbers.

On IA64 the above "show calls" command does NOT provide module names, routine names and line numbers. That is the problem.
It does if we instead use these commands

$ cc file /opt=noinline/debug
$ link image /debug
$ run image /nodebug/process=...

The problem for us with that is the /nodebug qualifier. Omitting it results in an attempt at automatic launch of the debugger and we don't want automatic launch of the debugger.

The programs of our product launches processes using sys$creprc() specifying the image file specification like this

sys$creprc(...,image,...);

The only way we know of of disabling launch of the debugger would be to instead use the input file specification argument of sys$creprc() like this

sys$creprc(...,image,input,...);

where image now instead specifies sys$system:loginout and the input specifies a DCL that specifies the above run command with the "/nodebug" qualifier.
But we have not been involving and don't want to involve a CLI (DCL) when calling sys$creprc(). Besides, we would have to make quite a few changes to implement such change.

How can we specify to sys$creprc() to disable launch of the debugger without involving DCL? How does the OpenVMS "run" command do it when specified with "/nodebug"? None of the options for behavioral change of the sys$creprc system service (PRC$M_* according to the system services reference manual) will disable launch of the debugger as far as I can tell.

[Richard Whalen]

You could link the image without /debug but with /dsf to produce a file that contains the debugger symbols. The debugger can then be told to use this file.

http://h71000.www7.hp.com/doc/83final/4548/4548pro_024.html#index_x_626

[Hoff]

Instead of doing all this manually, create a simple tool which launches the application for you. Now here is the trick: create a DECterm device, and pass the WS device into the sys$creprc as the SYS$ERROR parameter. This is how DECW$DISPLAY gets defined in the target process. Alternatively, create the DECterm and pass in the created device as the input and output for the sys$creprc call.

Here's some CREATE_DECTERM code I wrote a while back which should get you some ideas...

http://h71000.www7.hp.com/DOC/731FINAL/5841/5841pro_004.html

And don't operate in isolation here, either. Integrate debugging tools and assists directly into your application code. External tools are only so good. Integrated tools and tracing make it far easier to figure out what is going on.

Oh, and another sneaky trick is to build with the debugger and activate a null debugger when you don't need the debugger. (That's easy to code, and there are examples of a null debugger on the Freeware and elsewhere; look for the LIB$DEBUG stuff, as a start.) Alternatively, activate the real debugger with a debugger initialization file referenced via DBG$INIT logical name, and pass in a GO command and an EXIT command to skip the startup sequence.

[Claus Olesen]

Thank you for your replies and suggestions.

The "/dsf" option that you suggests works for what we need. The problem I have with it is that it produces an additional file (*.dsf) for each executable.
If the linker supported this command
$ link image /dsf/noexe
then the dsf file(s) could be produced right then and there only when and as needed by a software developer for debugging and deleted when no longer needed. Just like compiler *.lis files. Allthough which shareables to relink with "/dsf/noexe" might be a stepwise learning process.

The "activate a null debugger" approach that you suggests made me search the web a little more.
I stumpled on and discovered this command
$ set image /flags=nocall_debug

We never want automatic launch of the debugger so perhaps that can work for us.
On IA64 we'll then have to build everything for debug. Making that change is easy because everything is built using the same few scripts.

My test shows that an image file built for debug is about 50% larger than one without but a process running the image occupies about the same amount of virtual memory according to "show process /continous".
Are there any other negatives to using images built for debug in production?

[John Reagan · Accepted solution]

On I64, you can use the SET IMAGE command to turn off the debug flag after you LINK/DEBUG.

As for the larger image, the debug information is not mapped by the image activator. It is only mapped/used when the debugger is active. Other than more disk space and slightly longer link times, there isn't much downside to linking with debug and running without debug.