Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!bionet!csd4.milw.wisc.edu!bbn!mit-eddie!killer!pollux!ti-csl!m2!holland
From: holland@m2.csc.ti.com (Fred Hollander)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to do a LEGAL tail-patch
Message-ID: <70133@ti-csl.csc.ti.com>
Date: 16 Feb 89 20:29:33 GMT
References: <1272@ccnysci.UUCP>
Sender: news@ti-csl.csc.ti.com
Reply-To: holland@m2.UUCP (Fred Hollander)
Organization: TI Computer Science Center, Dallas
Lines: 38

In article <1272@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes:
>
>I've been thinking about this for a couple of days now. Here's my scheme.
>Does anyone see any flaws?
>
>Procedure MyPatch
>SetTrapAddress to original trap address
>Trap to original trap using A-line instruction

Apple uses come-from patches to patch ROM in traps that are called by
buggy traps rather than replacing the entire trap.  They check the
return address to see if they should act.  The trap address doesn't
matter.  At this point, the patch will still see your code as the
return address and will not execute the bug fix.

>SetTrapAddress back to @MyPatch (&MyPatch for C people)
>Fixup stack and return

>So, what's the verdict?

A legal tail patch will check the return address and if in RAM, there
wouldn't be a come-from patch, so it's safe to execute your patch.  If
you just want to check the results of the trap, you can call the
original trap yourself, execute your code, then jump to the original
trap address, where it will now see the callers return address (in
ROM).  The only drawback is that the trap gets called twice which why
it's referred to as a come-again patch :).

>
>Alexis Rosen
>alexis@ccnysci.uucp

Fred Hollander
Computer Science Center
Texas Instruments, Inc.
hollander@ti.com

The above statements are my own and not representative of Texas Instruments.