[M3devel] Static chains

[Rodney M. Bates]

Think of the debugger as an interpreter for a substantial subset of the
language.  When the program is stopped at some point, m3gdb can, in effect,
inject code to evaluate an arbitrary expression, typed by the debugger
user, or execute an arbitrary assignment or call statement.  Although
there are a number of gaps yet in the implementation, m3gdb is approaching
fitting this description.

The user-typed code can both create and use static link values that do
not occur in the original code that the compiler saws.  The simplest
example is, when stopped in a nested procedure, the user types
'print NonLocalVariable'.  This works fine right now, unless the compiler
has not stored the SL in the current proc's activation record, which a
compiler might well do if the nested proc, as coded, has no references
to any nonlocal variables.  (Or keeps the SL only in a register, etc.)

You could say this is only a convenience, as the user could work around
it by just typing 'up' the exact number of times to get to the static
parent's frame (which is, of course, also a dynamic ancestor).  But that
can slow down debugging a great deal, and I often find it a very important
convenience.  Anyway, you could say that to a degree about much of what a
debugger does.

A more complex example might be 'print Nested1(Nested2,NonlocalVar)',
where Nested1 and Nested2 are nested procedures.  Here, the debugger
has create and pass the appropriate SL value in order to call Nested1,
which, unless Nested1 is one scope deeper than the current stop point,
also entails m3gdb's fetching the SL that was given to some procedure
on the current dynamic call chain.  The same things are required of
m3gdb to construct the closure for Nested2, which it must pass to Nested1.
And if NonlocalVar is in an outer scope where Nested1 and/or Nested2
aren't visible, there would be no workaround possible at all.

Tony, I haven't been able to try out your latest change anyway, as
I seem to have once again regressed to not being able to get CM3 to
link to a working version of libpthread on Mandriva.  Also, I am about
to travel for a week, so may be out of this discussion for a while.


Tony Hosking wrote:
> Rodney,
> 
> I just realised that the static chains variables are *not* always  being 
> set up for nested function internal use.  i.e., callers will  pass them, 
> but nested functions that don't explicitly use them will  not have a 
> static chain.  Is this something essential for you?  Why  would you need 
> a static chain from within a nested function that  doesn't use any outer 
> scope variables?  Since it doesn't use any  outer scope variables they 
> cannot affect its execution, so debugging  the value of those variables 
> seems unnecessary.  This is the default  behavior of gcc for static chains.
> 
> -- Tony
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu