Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ames!ncar!boulder!pratt
From: pratt@boulder.Colorado.EDU (Jonathan Pratt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to do a LEGAL tail-patch
Message-ID: <6719@boulder.Colorado.EDU>
Date: 17 Feb 89 18:38:25 GMT
References: <1272@ccnysci.UUCP> <6541@hoptoad.uucp> <293@berlin.acss.umn.edu>
Sender: news@boulder.Colorado.EDU
Reply-To: pratt@boulder.Colorado.EDU (Jonathan Pratt)
Organization: University of Colorado, Boulder
Lines: 31

In article <293@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes:
(about making legal tail patches)
>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
...
>	proc	MyTailPatch
>	... do my post processing...
>	bclr	#TrapBit,YYY(SP)	; turn off single stepping
>	RTE

Am I missing something?  This doesn't make sense to me.  RealTrapAddr is
set to the address of some trap routine, most likely one that obeys a
pascal calling convention.  There are no return flags once a trap routine
has been called.  At least in the Plus, the trap dispatcher disposes of
them immediately.  Am I wrong to think that this strategy hinges on
trap routines using RTE's, which of course they don't?

Jonathan

/* Jonathan Pratt          Internet: pratt@boulder.colorado.edu     *
 * Campus Box 525              uucp: ..!{ncar|nbires}!boulder!pratt *
 * University of Colorado                                           *
 * Boulder, CO 80309          Phone: (303) 492-4293                 */