<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself.<BR>
 <BR>
Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc.<BR>
 <BR>
An non-optimizing compiler, sure, I guess.<BR>
 <BR>
Though it seems some level of optimization should be always on.<BR>
It pains me to think that every little function call I write might be made, and not inlined.<BR>
Microsoft compilers now do inlining across static lib boundaries.<BR>
Or that constant arithmetic like:<BR>#define A 1<BR>
#define B 2<BR>
int c = (A + B)<BR>
 <BR>
might be computed at runtime.<BR>
 <BR>
Or that <BR>
while(1)<BR>  ..<BR>
  .. if ... break;<BR>
 <BR>
might generate a runtime check if 1 is not zero (along with the code bloat).<BR>
 <BR>
Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function.<BR>
 <BR>
 - Jay<BR><BR><BR>> Date: Mon, 14 Jan 2008 17:24:35 -0600<BR>> From: rodney.bates@wichita.edu<BR>> To: hosking@cs.purdue.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Static chains<BR>> <BR>> Think of the debugger as an interpreter for a substantial subset of the<BR>> language. When the program is stopped at some point, m3gdb can, in effect,<BR>> inject code to evaluate an arbitrary expression, typed by the debugger<BR>> user, or execute an arbitrary assignment or call statement. Although<BR>> there are a number of gaps yet in the implementation, m3gdb is approaching<BR>> fitting this description.<BR>> <BR>> The user-typed code can both create and use static link values that do<BR>> not occur in the original code that the compiler saws. The simplest<BR>> example is, when stopped in a nested procedure, the user types<BR>> 'print NonLocalVariable'. This works fine right now, unless the compiler<BR>> has not stored the SL in the current proc's activation record, which a<BR>> compiler might well do if the nested proc, as coded, has no references<BR>> to any nonlocal variables. (Or keeps the SL only in a register, etc.)<BR>> <BR>> You could say this is only a convenience, as the user could work around<BR>> it by just typing 'up' the exact number of times to get to the static<BR>> parent's frame (which is, of course, also a dynamic ancestor). But that<BR>> can slow down debugging a great deal, and I often find it a very important<BR>> convenience. Anyway, you could say that to a degree about much of what a<BR>> debugger does.<BR>> <BR>> A more complex example might be 'print Nested1(Nested2,NonlocalVar)',<BR>> where Nested1 and Nested2 are nested procedures. Here, the debugger<BR>> has create and pass the appropriate SL value in order to call Nested1,<BR>> which, unless Nested1 is one scope deeper than the current stop point,<BR>> also entails m3gdb's fetching the SL that was given to some procedure<BR>> on the current dynamic call chain. The same things are required of<BR>> m3gdb to construct the closure for Nested2, which it must pass to Nested1.<BR>> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2<BR>> aren't visible, there would be no workaround possible at all.<BR>> <BR>> Tony, I haven't been able to try out your latest change anyway, as<BR>> I seem to have once again regressed to not being able to get CM3 to<BR>> link to a working version of libpthread on Mandriva. Also, I am about<BR>> to travel for a week, so may be out of this discussion for a while.<BR>> <BR>> <BR>> Tony Hosking wrote:<BR>> > Rodney,<BR>> > <BR>> > I just realised that the static chains variables are *not* always being <BR>> > set up for nested function internal use. i.e., callers will pass them, <BR>> > but nested functions that don't explicitly use them will not have a <BR>> > static chain. Is this something essential for you? Why would you need <BR>> > a static chain from within a nested function that doesn't use any outer <BR>> > scope variables? Since it doesn't use any outer scope variables they <BR>> > cannot affect its execution, so debugging the value of those variables <BR>> > seems unnecessary. This is the default behavior of gcc for static chains.<BR>> > <BR>> > -- Tony<BR>> > <BR>> > <BR>> <BR>> -- <BR>> -------------------------------------------------------------<BR>> Rodney M. Bates, retired assistant professor<BR>> Dept. of Computer Science, Wichita State University<BR>> Wichita, KS 67260-0083<BR>> 316-978-3922<BR>> rodney.bates@wichita.edu<BR><BR><br /><hr />Put your friends on the big screen with Windows Vista® + Windows Live™. <a href='http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008' target='_new'>Start now!</a></body>
</html>