Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!helios.ee.lbl.gov!ux1.lbl.gov!beard
From: beard@ux1.lbl.gov (Patrick C Beard)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSP/THINK Code Resource question
Message-ID: <2934@helios.ee.lbl.gov>
Date: 4 Jul 89 08:25:55 GMT
References: <4246@tank.uchicago.edu>
Sender: usenet@helios.ee.lbl.gov
Reply-To: beard@ux1.lbl.gov (Patrick C Beard)
Distribution: na
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 35

In article <4246@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes:
>
>I'm writing an MDEF with LSP/THINK Pascal.  Near the start of my MDEF I call a
>sub-procedure in which I allocate a pointer with NewPtr (which I dispose of
>before exiting the  MDEF).  While debugging (with TMON), I intercepted the
>NewPtr call, but the NewPtr call  isn't in my sub-proc any longer, but rather
>it's near the start of main the code. I think this section of main code is
>called from my sub-proc and then jumps back there.  Any idea of what's going
>on?  It's more difficult to debug when the assembly differs greatly from the
>source (i.e, why is my NewPtr call not in the section of code (my sub-proc)
>where it "should" be?).

This is because all calls to Memory Manager traps are handled through
glue.  i.e.,  NewPtr(sizeof(variable)) becomes...

CallToNewPtr:
    CLR.L   -(SP)                   ; save space for result
	MOVE.L  #sizeof_variable,-(SP)  ; push size
    JSR     NewPtrGlue
    ...
NewPtrGlue:
    MOVE.L  (SP)+,A1    ; save return address.
    MOVE.L  (SP)+,D0    ; get size of ptr request
    _NewPtr             ; call trap.
    MOVE.L  A0,(SP)     ; put address back on stack
	JMP		(A1)        ; get out of this.

I hope this answers your question.

__________________

   Patrick Beard
  PCBeard@lbl.gov
 BSI, Berkeley, CA
___________________