Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!usc!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <5436@internal.Apple.COM>
Date: 27 Nov 89 22:55:27 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 43
References:<1459@sequent.cs.qmc.ac.uk> <36250@apple.Apple.COM>        <5056@internal.Apple.COM> <1989Nov7.212837.5146@oracle.com> <TIME.89Nov27160228@oxtrap.oxtrap.UUCP>

In article <TIME.89Nov27160228@oxtrap.oxtrap.UUCP> time@oxtrap.oxtrap.UUCP 
(Tim Endres) writes:
> Has Apple looked into some OS mechanism that provides ROM patching?
> Like, bless and condone patching in a "supported" manner. Just curious.

Yes, various groups within Apple have looked at doing this.  There are a 
variety of problems.  One problem is the one that's been under discussion, 
which, for the sake of completeness, goes like this:

1) A bug is discovered in some ROM routine.  The routine may be fairly 
   large.
2) Rather than replace the entire largeish routine in RAM, Apple fixes the 
   bug by patching the code for some trap that the broken routine calls.
3) The patch for the trap, when called, looks at some offset on the stack 
   for a return address to the broken routine so as to ensure that, within the 
   context of this invocation, it was indeed called from the broken routine.
4) If the address comparison comes out equal, some code that fixes the 
   problem is executed.  Otherwise the trap goes about its normal business.

Tail patching (that is, replacing a trap definition in such a way that the 
original code is effectively JSRed to rather than JMPed to) is bad because 
effectively JSRing to the original code screws up the stack offsets and 
therefore screws up the return-address comparison, so the fix code never 
gets executed at all.  Oops.

Anyway, another potential problem with even a sanctioned way to patch 
traps is that the patch may not completely obey the letter of the law (for 
example, a trap may be callable at interrupt time, but the patched version 
may not.  Or a trap may be guaranteed not to move memory, but the patched 
version may allow for a heap scramble).  Unfortunately, there's no a 
priori way to know what a patch is going to do.  As a friend of mine who 
writes Macintosh applications puts it, "not only am I programming my 
users' Macintoshes, but everyone whose INITs and cdevs that my users are 
using is programming my users' Macintoshes."

Hope this helps.

__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________