This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCC tree access & Pretty-print


Pop,

Thankyou for the information you sent me last December regarding trees.  I have not
had time until now to work on this pet project of mine to create a source browser,
but I recently picked it up again.  Of course, I have had to refamiliarize myself
with the little bit of code I had viewed before to see how to get the information I
want.

I was wondering if you (or anyone else at gcc.gnu.org) could tell me how the
pretty-print capability works?  I see alot of code starting with
pp_c_pretty_printer_init, but I cannot decern how it is used.  Is this a debugging
capability that has to be turned on in the code?  If so, how do you do so?

As before, any examples that anyone can provide for either the pretty-print stuff,
or accessing trees in general would be greatly appreciated.

Also, If anyone has instructions on the best way quickly test changes to the gcc
code, I would like to see them.  I downloaded the CVS tree, did a "configure" to
/usr/local, did a "make bootstrap", and then a "make install".  I find that to test
changes I need to do a "make" in objdir, and then do another "make install" (as
root), to get the changes.  The "make install" takes quite a bit of time.  Is there
a faster way to test changes that I make to the code?

Thanks for the help

Jeff Richardson
jlrichardson at link dot com

Pop Sébastian wrote:

> Hi,
>
> On Fri, Dec 06, 2002 at 11:43:32AM -0500, Jeffrey Richardson wrote:
> > > >
> > > > I am interested in developing a combination "intelligent editor" and
> > > > source browser using the tree structure created internally by GCC, as
> > > > described in the article on trees in the GCC Internals manual.
> > > >
> Have a look at http://gcc.gnu.org/projects/tree-ssa/tree-browser.html
> This is (for the moment) just a debugging tool, but it could be extended
> into an interactive source browsing/editing tool.
>
> > > > My question is this:  if I write my own version of "precess_stmt" which
> > > > uses the macros to access various tree information and write it out to a
> > > > file, where is the best place to call my function?  Can it be called
> > > > from a single location (such as finish_function), and still have access
> > > > to the full tree structure?
> > > >
> Yes.
> You can use TB for experimenting during a gdb session and see what information
> is available at a given point of the compiler.
>
> Ouch... I just realised that there's no link to a page explaining how to
> debug GCC using GDB.  Is there any page that contains these bits?
> Otherwise I'll write one from scratch.
>
> > > > Also, what is the "permanence" of the tree structure.
> For the moment in tree-ssa branch you cannot store tree structures into a file.
> However this operation was implemented in pch-branch, and thus it could be
> included in tree-ssa-branch once pch-branch stabilize.
>
> > > > As a source file
> > > > is parsed, and the tree structure is constructed, is there a point at
> > > > which branches of the tree are discarded because they are no longer
> > > > needed (e.g. when a function has been completed),
> yes, once trees were translated into RTL garbage collector is called and
> tree structures for function's body are freed.
>
> I think that there's a possiblilty to make GCC keep all functions from a
> compilation unit in memory simply by avoiding to go into rest_of_compilation.
>
> For handling projects with multiple files we'll need a load_tree operation
> (already implemented in pch-branch I think).
>
> A source editing tool working on top of GCC could improve development style,
> productivity, and code understandability (for example class hierarchy, call-
> graph,... are for free when you work with ASTs).  Moreover the programmer
> could focus on a small part of the code and optimize it locally.  One could
> even imagine more interaction when the compiler could extract information by
> questioning directly the programmer.
>
> > > > or is there a point at
> > > > which a complete tree exists for the entire source file, which would
> > > > therefore be the best time to call a function to output a "snapshot" of
> > > > the tree?  (I guess this is actually a re-statement of my first
> > > > question.)
> > > >
> just before genrtl_ expanders (expr.c).
>
> > > > If there are any examples or code fragments of similar applications that
> > > > you can share with me, I would very much appreciate it.
>
> Yes, two weeks ago I contributed tree-browser.c in tree-ssa branch.
>
> For checking this branch out, have a look at the instructions:
> http://gcc.gnu.org/projects/tree-ssa/index.html
>
> Sebastian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]