Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!oliveb!epimass!pyramid!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Register saving conventions
Message-ID: <15093@apple.Apple.COM>
Date: 2 Aug 88 20:04:33 GMT
References: <664@iraun1.ira.uka.de> <10050005@eecs.nwu.edu>
Reply-To: lsr@apple.apple.com.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 23

In article <10050005@eecs.nwu.edu> bob@eecs.nwu.edu (Bob Hablutzel) writes:
>processes AFTER the ROM code). MultiFinder is making tail patches very
>hard to impliment, as the MultiFinder code often checks to see where
>it comes from, or it can depend on the ROM code leaving certain registers
>in specific states. I think Apple is quietly saying that tail patches
>are no longer valid, although I have not heard this verbatum from Apple.

Tail patches have always been questionable, even before MultiFinder.  Bugs
in the ROM are often fixed using the technique of looking at return
addresses (known as "come-from patches").  

Instead of replacing the entire buggy routine (which might be large), a
patch is made at a trap called just before the bug.  The patch looks at the
return address to see if it really is just before the bug.  If so, it fixes
the bug and jumps back into ROM.

The recommended way to patch a trap is to call the original routine with the
stack in the same state as you found it (ie, with the same return address).

		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr