Craig A. Berry wrote:
At 9:59 PM -0500 2/2/06, John E. Malmberg wrote:
I am currently building a patch that allows Perl to enter the
OpenVMS debugger when an exception occurs, if the the logical name
PERL_EXCEPTION_DEBUG is present.
What I could use some help in creating a perl script that would
cause an exception to be signaled so that I can verify that it works.
Just about anything that sets errno should generate an exception I
would think. How about opening a file that does not exist:
$ perl -e "open F, '<', 'nonexistentfile'; print $^E;"
%RMS-E-FNF, file not found
That does not generate a "FATAL" exception.
By now you should have seen the patch that I wrote. What I am doing is
allowing the default perl fatal exception handler to optionally invoke
the VMS debugger just before the program exits.
This allows you to look at the state of the program where the exception
occurred with out running the program in debug.
Also, to fully take advantage of this feature, all compiles should
always be /DEBUG/OPTIMIZE on ALPHA and I64 for non-debug builds.
On ALPHA and I64, the link procedure should always be /DSF which
will create a debug symbol file (.DSF) external to the image. This
.DSF file can be used in case the distributed binary needs debugging,
>> but keeps the binary files small.
I do not know how to change the build procedure to take advantage
of this on the three platforms because of it's complexity.
Hmm. I did not know about /DSF. Does the debugger automatically
find the .DSF files if they are in the same directory as the
executables?
I have not researched it fully, but I think that it has a number of
places that it will look for it by default, and uses a similar method
that the debugger uses to find the source files.
The main difficulty I see is that these files would
have to be installed, which would involve modifications to
installperl and to MakeMaker and Module::Build.
Actually the DSF file would not get installed normally, just like the
source is not copied, but it should be kept with the build output files
in case it was needed. Yes, that is a packaging and documentation issue.
The big advantage of using the DSF file is that on ALPHA, you only need
to build a special debug/nooptimize version under rare circumstances as
there is a mode you can set in the debugger to make it step like in the
original code is written. (I do not remember how to set that mode at
the time I am typing this).
The /DEBUG flag on the linker controls if the debugger is invoked when
the image is started.
With IA64, I am told that it is currently not practical to debug
optimized binaries, and this feature is still being researched. But in
the case of this last chance handler, stepping through code is not a
practical option, so having the compile /debug/optimize and the link
with the DSF file would still work.
I am use to debugging optimized binaries on the VAX, but others may not
be. Unfortunately the VAX linker does not support putting the debug
symbol table in a separate file.
So I think there will always be a need for a /DEBUG/NOOPTIMIZE as a
build option, but at least on Alpha, it is possible to set up an
alternative.
I would suggest that as a first cut we only implement the
PERL_EXCEPTION_DEBUG option for builds created with -Dusevmsdebug.
The debug symbols would already be in the executable in that case.
Then we can take on adding /DSF capabilities as a separate project.
With out the debug symbols in the image, the feature still has use as it
can be compared against the linker maps.
The patch I submitted is always built in on the versions of VMS that
implement the SS$_DEBUG symbol in ssdef.h.
-John
[EMAIL PROTECTED]
Personal Opinion Only
