RE: Using the tree.

RE: Using the tree.

[Virgil Palanciuc]

> >      It is for the C front end. I had some doubts whether this
> will work or
> > not - but I supposed that since it doesn't crash, it should
> work. Besides, I
> > can find out the parameters, or the return type for my
> function, but there
> > seems to be nothing there about the local variables.
>
> The problem is that getdecls returns the declarations *of the current
> binding level*. That is, when a binding level is closed, the decls
> list is lost. At the end of the function, only the binding level of
> the parameters is still open.

    Yes, this looks like the explanation. But what *exactly* does 'a binding
level is closed' mean? Is the info still there (I think it should) ? Do I
have another way to get it? How?

   Virgil.

Re: Using the tree.

[Martin v. Loewis]

>     Yes, this looks like the explanation. But what *exactly* does 'a
> binding level is closed' mean?

A binding level is a C block:

void foo(int x) /* binding level for parameters */
{               /* a new binding level opens */
  int i;
  for (i=0;i<10;i++){ /* a new binding level opens */
    int k;
  }                   /* the binding level containing k closes */
}               /* the binding level containing i closes */



> Is the info still there (I think it should) ?

I don't think so: information on local variables is lost once the
block closes; this is the "statement at once" mode of RTL generation.
Only in the "function at once" mode, such information is preserved to
the end of the function.

In the RTL, the variables are represented by registers, which may or
may not be alive. I don't think you can reconstruct the declarations
from them.

Regards,
Martin

RE: Using the tree.

[Virgil Palanciuc]

> >     Yes, this looks like the explanation. But what *exactly* does 'a
> > binding level is closed' mean?
>
> A binding level is a C block:
>
> void foo(int x) /* binding level for parameters */
> {               /* a new binding level opens */
>   int i;
>   for (i=0;i<10;i++){ /* a new binding level opens */
>     int k;
>   }                   /* the binding level containing k closes */
> }               /* the binding level containing i closes */

    Thanks, but you misunderstood me (my fault :) )
    I know what 'a binding level is closed' means in terms of C language
(from the programmer's point of view), I wanted to know what it means in
terms of gcc (how this 'event' affects the data structures and so on).
However, I think you answered my question below.

> > Is the info still there (I think it should) ?
>
> I don't think so: information on local variables is lost once the
> block closes; this is the "statement at once" mode of RTL generation.
> Only in the "function at once" mode, such information is preserved to
> the end of the function.
>
> In the RTL, the variables are represented by registers, which may or
> may not be alive. I don't think you can reconstruct the declarations
> from them.

     I know I can't - I tried to, but I failed. This is why I resorted to
the tree - I tried to avoid this because I don't really know how to handle
the tree.
     Anyway, there must be a way to find out what stack slot is assigned to
each variable (and to find out this info about arrays, too !!! ).
Ultimately, this information can be obtained in the parsing step and
memorised in a different data structure until needed. This is an ugly yet
safe solution - but I don't know how (and *exactly* when) to do that,
either.

> Regards,
> Martin

       Virgil.

Re: Using the tree.

[Martin v. Loewis]

>      Anyway, there must be a way to find out what stack slot is assigned to
> each variable (and to find out this info about arrays, too !!! ).
> Ultimately, this information can be obtained in the parsing step and
> memorised in a different data structure until needed. This is an ugly yet
> safe solution - but I don't know how (and *exactly* when) to do that,
> either.

Since the information you need is in the debugging information, you
may want to trace how debugging information is generated for a function.

Regards,
Martin

Re: Using the tree.

[Richard Henderson]

On Sun, May 28, 2000 at 09:00:52PM +0300, Virgil Palanciuc wrote:
>      Anyway, there must be a way to find out what stack slot is assigned to
> each variable (and to find out this info about arrays, too !!! ).

See DECL_RTL on the VAR_DECLs and PARM_DECLs in question.

If you're wanting to do some sort of post-processing on
code, you might have an easier job examining the debug 
output instead of mucking about inside the compiler.


r~

RE: Using the tree.

[Virgil Palanciuc]

> We expect that you'll do some digging.
    I did. The answer was incredibly obvious (but only AFTER I found it). I
could get all the information I needed in rest_of_decl_compilation, in
toplev.c. And it was quite simple to get it, too. The ironic thing is that I
knew about the existence of rest_of_decl_compilation, but I never thought to
look at it until I tried to track down how the debugging information is
generated (that's what put me on the right track).

> pop_binding_level. ...  You get the idea.  All these are simple
> answers and aren't necessarily complete or accurate, but they should
> get you looking at the right code and on the right track.
    They didn't - they actually put me on the wrong track. I lost a LOT of
time doing this.

> If you play around a bit before asking them, we
> hope that you will be able to answer your own questions before we have
> to.  If you fail to do this, some that could answer may just ignore
> all your questions.

     I know you are all extremely busy and I tried not to bother you with
every problem I had. I asked this question because I got very near a
deadline and I had no more time to do all the digging - I imagined it was I
simple question and that I will get the answer right away (which I didn't,
but i DID get a suggestion that put me on the right track).
     Anyway, I don't agree with what you said. If you people stop answering
the simple questions, the chances of having new people become familiar with
the gcc source code will diminish dramatically. With your help I was able to
understand gcc, and  - as opposed to 4 months earlier, when I thought
somebody(i.e. I) is unlikely to be able to improve gcc any furher - now I
KNOW gcc CAN be improved. A lot. And most importantly, because you answered
my (in fact, our) simple questions, we were able to produce some concrete
results and I hope we will be suppported (starting from this autumn) to
start some REAL work on gcc. If this shall prove to be true, you may all
benefit from our work here - so you see, answering simple questions may be
important, too.

    Thanks again for taking the time to answer our questions.

         Virgil.

Re: Using the tree.

[Joern Rennecke]

> pop_binding_level. ...  You get the idea.  All these are simple

It's called poplevel.

RE: Using the tree.

[Mike Stump]

> From: "Virgil Palanciuc" <Virgil.Palanciuc@cs.pub.ro>
> To: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> Cc: <gcc@gcc.gnu.org>
> Date: Sun, 28 May 2000 21:00:52 +0300

>      Anyway, there must be a way to find out what stack slot is
> assigned to each variable (and to find out this info about arrays,
> too !!! ).  Ultimately, this information can be obtained in the
> parsing step and memorised in a different data structure until
> needed. This is an ugly yet safe solution - but I don't know how
> (and *exactly* when) to do that, either.

We expect that you'll do some digging.  The answer is roughly
DECL_RTL.  The next question becomes how can I find the decls.  That
answer then becomes getdecls.  The next question is when to call it.
The answer to that is at the end of each binding contour.  The next
question is when does a binding contour end, the answer to that is
pop_binding_level. ...  You get the idea.  All these are simple
answers and aren't necessarily complete or accurate, but they should
get you looking at the right code and on the right track.  Once you
get into the code in the debugger, and start playing around, it will
become familiar and predictable.  You can then ask more interesting
questions with more interesting answers...  I am sure that you can ask
hundreds of questions with little thought.  That will swamp our desire
to answer in general.  If you play around a bit before asking them, we
hope that you will be able to answer your own questions before we have
to.  If you fail to do this, some that could answer may just ignore
all your questions.

Re: Using the tree.

[Martin v. Loewis]

>      I am trying to obtain all the variables declared in a function using
> (to build a 'memory map'). I don't think I can find what I want from the
> RTL - I tried that (I can't find arrays declared in a function).
> 	I do something like:
> 
>     for(tmp=getdecls();tmp;TREE_CHAIN(tmp))
> 		debug_tree(tmp);
> 
>     I looked through the output and I can't find any rel;evant information
> (there doesn't seem to be anything in the output related to my variables -
> only my function's name and a LOT of builtins).
> 
> 	What should I do get the information I need?

What front-end is this for? I don't think all front-ends support such
a function. In the C++ front-end, due to the function-at-once mode, it
should be possible to walk the tree and find all var_decls.

Regards,
Martin

Using the tree.

[Virgil Palanciuc]

     I am trying to obtain all the variables declared in a function using
(to build a 'memory map'). I don't think I can find what I want from the
RTL - I tried that (I can't find arrays declared in a function).
	I do something like:

    for(tmp=getdecls();tmp;TREE_CHAIN(tmp))
		debug_tree(tmp);

    I looked through the output and I can't find any rel;evant information
(there doesn't seem to be anything in the output related to my variables -
only my function's name and a LOT of builtins).

	What should I do get the information I need?

   TIA,
    Virgil