CLAYTON@xrt.upenn.EDU ("Clayton, Paul D.") (07/13/87)
Information From TSO Financial - The Saga Continues...
Chapter 9 - July 12, 1987
David Stevens has the following code which is a kernal mode routine that is
crashing the system.
.entry lat_info,^M<r2,r3,r4,r5,r6>
.
.
.
info: tstb srv_name_len
beql 40$
movl ap_name(ap),r3 ; Get the return name buf addr
movc3 srv_name_len,srv_name_str,(r3)
40$: tstb port_len
beql 50$
movl ap_port(ap),r4 ; Get the return port buf addr
movc3 port_len,port_numb,(r4)
.
.
.
ret ; that's all folks!
In this first case, what I see is that the LENGTH is a BYTE variable that
is first tested. If I can assume such, then the cause of the crash is due
to the fact that the MOVC3 instruction uses a WORD, not a BYTE, to define the
length of the data string to move. The result of the code above is that the
length is a byte, my assumption, and the next byte after the length you are
pointing to is a NON-ZERO value. The result is CONSIDERABLE more data moved
then expected, followed shortly there after with a resounding crash.
In the code that follows the above section, I noticed as Jerry did that the
registers 2 through 5 are NOT saved in the register mask. BUT in this section
the following WAS done for the length of data to move for the MOVC3.
movzbw (r8), port_len ;; Get the length of port string
beql srvinf ;; If Zero length then branch
;;
;; Move the data into the storage area
;;
movc3 port_len, srv_info_port(r8), (r6)
.
.
movzbw srv_info_port(r8), srv_name_len
beql finish ;; If Zero length then branch
.
.
ret ;; back to user mode
The result is the right length being moved but R2,R3,R4 and R5 are replaced
with new values and the next higher code segment, who knows what it may be,
now has rubbish, as far as its concerned, in those registers.
Those two fixes should do the trick if I am reading the code correctly. Hope
these answers help.
Paul D. Clayton - Manager Of Systems
TSO Financial - Horsham, Pa. USA
Address - CLAYTON%XRT@CIS.UPENN.EDU