Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!lts!amanda
From: amanda@lts.UUCP (Amanda Walker)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to do a LEGAL tail-patch
Message-ID: <889@lts.UUCP>
Date: 17 Feb 89 14:22:49 GMT
References: <1272@ccnysci.UUCP> <6541@hoptoad.uucp> <293@berlin.acss.umn.edu>
Reply-To: amanda@lts.UUCP (Amanda Walker)
Organization: InterCon Systems Corporation, Reston, VA
Lines: 35

grg@berlin.acss.umn.edu (George Gonzalez) writes:
    
    I've thought about this problem too.  Here's a scheme that might work.
    
    	RealTrapAddr := GetTrapAddress( TheTrap );
    	SetTrapAddress( TheTrap, OurHookProc );
    	PokeLong( @MyTailPatch, SingleStepInterruptVector );
    
    	proc OurHookProc;	; gets called by the trap dispatcher.
    	bset	#TrapBit,XXX(SP)	; set single step trap bit in ret flags
    	PushL	RealReapAddress		; a registerless "jump"
    	RTS
    
    Besides the obvious problem of being able to patch only one trap at a time,
    and needing different XXX and YYY offsets for 68000 and 68020+, this idea
    *might* just work.

It's a pretty clever idea, although it would be real annoying to try
and debug (since most debuggers like to use the Trace feature for,
well, tracing...).  You can solve the processor problem by checking
CPUflag when you install the patch.

This is probably unworkable in general, though, for two reasons: only
one patch can use the mechanism at a time, and it might not work in
environments where the processor is not running in supervisor mode,
such as A/UX, MacOS with a virtual memory INIT, the prophesied MacOS
rewrite, etc...

But definitely clever :-)...

-- 
Amanda Walker			...!uunet!lts!amanda / lts!amanda@uunet.uu.net
			  InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...