[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.