[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers

Title:** Hackers **
Moderator:XDELTA::HOFFMAN
Created:Mon Feb 01 1988
Last Modified:Tue May 27 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1838
Total number of notes:13578

1831.0. "SYS$EXIT " by GALVIA::FOX_F () Mon Mar 24 1997 09:39

    Hi, 
    
    Is it possible to get the source code for SYS$EXIT routine. In 
    my porting project (VAX to ALPHA) there are some tests created using 
    VAX BASIC which test the application. Everything seems to run fine until 
    the test program calls sys$exit at the very end and the program 
    access violates trying to access the VA FFFFFE60 ... The application 
    is quite complex and a lot of the code that the BASIC tests exercise
    are VAX Macro routines that have been ported to ALPHA.  
    
    Thanks for any help, 
    John. 
T.RTitleUserPersonal
Name
DateLines
1831.1EEMELI::MOSEROrienteers do it in the bush...Mon Mar 24 1997 11:539
    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.2condition handlers on AXPGALVIA::FOX_FMon Mar 24 1997 14:4214
    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.3FP (R13) is an architectural register...XDELTA::HOFFMANSteve, OpenVMS EngineeringTue Mar 25 1997 12:5218
    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.4used a .call_entry GALVIA::FOX_FFri Mar 28 1997 14:187
    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.