[M3devel] dbxout_static_chain_decl?

[Jay K]

Rodney, When you get back to it, can you just dig it out of history?
 
 
I still think we should try to avoid gcc's nested function functionality.
 
 
Where you use the static chain, not using the nested function functionality should
"automatically" be debuggable -- "automatic" as in, once the work is done
in the frontend to transform out nesting.
 
 
"debuggable" as in, you could follow the links yourself in the debugger.
The debugger need not search lexically nested functions that have function
calls dividing them.
 
 
?
 
 
There's stuff I still need to understand better -- particularly the affect of nested functions
on non-nested functions. Is there *always* an extra parameter to *all* functions?
It appears so.
And I haven't figured out how to merge with 4.5 what I think achieves that.
 
 
Maybe a good test of test cases here?
 
 
 
 - Jay


----------------------------------------
> Date: Wed, 26 May 2010 17:37:07 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] dbxout_static_chain_decl?
>
> I left it in because it is a work in progress. I *really* want to get it to
> work, and I don't what to have to reinvent what is already there when I get
> to it. I use nested procedures extensively in certain situations, and good
> debugger support of them is important to me. It all works fine on older code
> generators than the gcc that added tree-nested.c.
>
> Jay K wrote:
>> Rodney, you added this function, along with a comment that says it doesn't actually work.
>> Does it work?
>> Does it accomplish anything?
>> Can I remove it and its calls?
>>
>> /* Special-purpose function to write stabs for the static_chain_decl.
>> So far, this is not working. m3gdb needs the place in the activation
>> record where the SL is stored. Right now, the SL is not necessarily
>> stored at all, but may just be kept in a register. DECL_RTL and
>> DECL_INCOMING_RTL may both have register expressions. But stabs
>> entries for register variables, of kind N_RSYM, are currently ignored
>> by gdb in dbxread.c, and making it read them could create problems
>> elsewhere, because there can be other variables for which both an
>> N_RSYM and an N_LSYM stabs entry are created.
>> */
>> static int
>> dbxout_static_chain_decl (tree decl)
>>
>> It was added 19 months ago by:
>> http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/dbxout.c.diff?r1=1.8;r2=1.9
>>
>> as well, do we need the #if 0 code added then?
>>
>> - Jay
>>