Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <5103@internal.Apple.COM>
Date: 9 Nov 89 19:20:43 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 59
References:<1459@sequent.cs.qmc.ac.uk> <36250@apple.Apple.COM> <5056@internal.Apple.COM> <1989Nov7.212837.5146@oracle.com>

In article <1989Nov7.212837.5146@oracle.com> omullarn@oracle.oracle.com 
(Oliver Mullarney) writes:

> OK - I understand why we shouldn't use tail patches, but sometimes
> you just gotta. How else can you catch a function result from a
> trap call?

As the Black Knight would say "No Way!"  If trap X has been tail patched 
to fix a bug, then your patch to trap X must call the original trap 
address with the same return address on the stack.  Otherwise the bug fix 
won't get activated.

> Instead of maintaining hard coded return addresses (a bad move anyway,
> considering TN 110, "Processor Compatibility", final para.) it would

Hard coding a ROM address means you are tied to a particular ROM.  Patches 
are already machine-specific, so it makes sense to use hard-coded 
addresses to simplify the patches.

> be possible to examine the trap table for the address of the trap of
> interest (in case it has been patched), scan forward from this address 
> to find the RTS, and check to see if the return address on the stack 

I don't think this would work, for several reasons.  First, I don't think 
you can do a simple scan.  I doubt that patches are written in a nice 
linear format.  

Second, your idea tries to determine if a call to Apple's patch (which 
checks the return address) came from the currently installed patch.  The 
problem is that a trap can be patched several times.  Your idea only 
checks the most recent patch.

Also, the whole idea of Apple's patches checking the return address is to 
determine where the *original* call came from.  The patch is intended to 
be activate only in one particular case, when it knows the state of the 
world and can fix the problem.

Suppose there is a bug in the ROM.  The System S/W people find a trap call 
in the ROM that occurs before the bug manifests itself.  They install a 
patch that watches for this particular call and fixes up the state of the 
machine to correct the problem.  This might involve changing a register or 
changing some value on the stack.  (I've never tried fixing bugs in the 
ROM, so I'm guessing at the exact process.)

The trap that's patches bears no relationship to the trap that contains 
the bug.  In fact, patches are likely to appear in frequently called 
routines (eg, Memory Manager routines, BlockMove, etc.), since they tend 
to be called in a lot of different places.

The only way to avoid patches that look at the return address would be to 
replace entire pieces of the ROM.  This would make bug fixes take up more 
RAM space that they do now.


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1