T.R | Title | User | Personal Name | Date | Lines |
---|
1831.1 | | EEMELI::MOSER | Orienteers do it in the bush... | Mon Mar 24 1997 08:53 | 9 |
| I'll bet they have some exit handlers declared somewhere in P0 space
and that VA range is probably long gone when the exit handlers are
called during SYS$EXIT (I mean prived exec or kernel mode exit handlers
in P0).
I've also seen folks forgetting to clear/delete exit handlers in their
condition handler routine before calling SYS$EXIT.
/cmos
|
1831.2 | condition handlers on AXP | GALVIA::FOX_F | | Mon Mar 24 1997 11:42 | 14 |
| Yes, there is something wrong in the condition handler.
The code works find on the VAX but accvios on the alpha. It fails
in a JSB_ENTRY routine that is called in by the exit handler routine to
clean up some memory allocations. The failing instruction attempts to
use R13 which has a value of 000000A0 in it and it crashes.
I read in the porting guide something about EVAX_TRAPB .. that on AXP
traps from instructions can be processed after the fp has been changed.
Could this be my problem.
thanks for any help,
John.
|
1831.3 | FP (R13) is an architectural register... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Mar 25 1997 09:52 | 18 |
|
We need to see the source code of the exit or condition handler and
the stack dump, at minimum. We also need information on the exact
environment the exit or condition handler is running in. (All we
presently know is that R13 -- a register better known as the frame
pointer (FP) -- is being used.)
I'd strongly recommend getting rid of the Macro32, in favor of using
C or some other language. Since the code was originally written in
Macro32, I'd suspect it is doing "weird" or "unusual" processing, and
this sort of thing is subject to porting problems. The references to
FP appear to confirm that this Macro32 code may include some sort of
architecture-specific coding techniques and/or references.
I will assume you have seen the guide to porting Macro32 code.
(And this note looks more like VMSNOTES fodder than HACKERS...)
|
1831.4 | used a .call_entry | GALVIA::FOX_F | | Fri Mar 28 1997 11:18 | 7 |
| Thanks for the help ....
I got rid of the problem by changing the entry points from JSB entries
to .CALL entries. It seemed to solve the problem ....
all the best,
John.
|