[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Can someone explain how this apparent magic happens



    Date: Thu, 18 Aug 88 01:20 PDT
    From: Siskind.pa@Xerox.COM

    I noticed that when you call a function say FOO which has
    an argument BAR and you look at FOO's stack frame in the
    debugger then BAR appears as a "Arg" slot in the stack frame.
    But if you later SETQ BAR to something else and then do a
    m-L in the debugger there are actually two entries for
    BAR, the first labeled "Arg" with the original value passed
    as a parameter, and the second labeled "Local" with the
    the new value just SETQed. If I access BAR, of course I
    get the new "Local" value. According to the naive expectation
    of what the system is doing, I would have though that
    a SETQ to an argument would simply overwrite the old value.
    But how (and why) does the system retain the original
    value and how does the system know how to get the old vs.
    the new value when I access BAR depending upon whether
    I have SETQed it?

Evaluate 1(locf (dbg:arg 0))0 and 1(locf (dbg:loc 0))0, and notice that they
are in different places.  The reason is that the 3600 copies its
arguments.

This is "fixed in the Ivory" which does not copy its args, at the
expense of some debuggability in the case where a function bashes its
arguments, then blows into the Debugger and you want to poke around or
re-invoke the function: the bashed arguments are forever bashed in the
Ivory, but on the 3600 you get both args and locals.

    To see my point, witness the following transcript:

      (defun foo (bar)
	(break)
	(setq bar 'quux)
	(break))
    FOO
      (compile 'foo)
    For Function FOO
      (BREAK) breakpoint in program
      (BREAK) breakpoint in program
    FOO
      (foo 'baz)
    Break: (BREAK) executed

    FOO
       Arg 0 (BAR): BAZ
    s-A, q:    Return from BREAK
    s-B, q:    Return to Breakpoint ZMACS in Editor Typeout Window 1
    s-C:           Editor Top Level
    s-D:           Restart process Zmacs Windows
     Meta-L Show Frame :Detailed Yes :Clear Window Yes
     Called to return, funcalled.

    FOO

     Arg 0 (BAR): BAZ

    Disassembled code:
	 0  ENTRY: 1 REQUIRED, 0 OPTIONAL
	 1  CALL-0-IGNORE #'BREAK
    =>   2  PUSH-CONSTANT 'QUUX
	 3  POP-LOCAL FP|0          ;BAR
	 4  CALL-0-RETURN #'BREAK
     Resume Proceed
    Return from BREAK
    Break: (BREAK) executed

    FOO
       Arg 0 (BAR): BAZ
    s-A, q:    Return from BREAK
    s-B, q:    Return to Breakpoint ZMACS in Editor Typeout Window 1
    s-C:           Editor Top Level
    s-D:           Restart process Zmacs Windows
     Meta-L Show Frame :Detailed Yes :Clear Window Yes
     Called to return, funcalled.

    FOO

     Arg 0 (BAR): BAZ
     Local 0 (BAR): QUUX

    Disassembled code:
	 0  ENTRY: 1 REQUIRED, 0 OPTIONAL
	 1  CALL-0-IGNORE #'BREAK
	 2  PUSH-CONSTANT 'QUUX
	 3  POP-LOCAL FP|0          ;BAR
	 4  CALL-0-RETURN #'BREAK
    => 

    What I want to know in particular, is if I muck arround and
    access stack frames via: SYS:%STACK-FRAME-POINTER and
    DBG:FRAME-PREVIOUS-FRAME and then get a locative to a slot
    in a stack frame via:

    (SETQ BAR-LOCATION
	  (SYS:%MAKE-POINTER-OFFSET SYS:DTP-LOCATIVE FRAME-OF-INTEREST 0))

    where I know that in the FRAME-OF-INTEREST the desired argument
    (say BAR as in the above example) is in slot 0 then does
    BAR-LOCATION point to "Arg 0" or to "Local 0" i.e. BAZ or QUUX?
    Can I be assured of this? What about both before and after I
    do the first (SETQ BAR ...)? What happens if I do a
    (SETQ (LOCATION-CONTENTS BAR-LOCATION) ...)? Do I change "Arg 0"
    or "Local 0"? How can I access the alternate value? In general,
    can someone please explain to me exactly what is going on here.

It points to local slot 0.  Look at the functions 1dbg:frame-arg-value
0and 1dbg:frame-local-value0.

    Please don't warn me that I am going to lose by mucking arround
    with stack frames, there is a very compelling reason why I am
    doing so. I understand that my code won't work on future machines
    and under future releases but I still want to do what I am
    doing.

Well, I'll warn you anyway: you're going to lose by doing this.  In
particular, you will lose on Ivory.

For my own curiosity, I would like to know what this compelling reason
is, since my feeble imagination cannot come up with anything.