[GCC-XML]Re-write prototype in CVS

David Abrahams david.abrahams at rcn.com
Thu Mar 14 07:59:41 EST 2002


----- Original Message -----
From: "Brad King" <brad.king at kitware.com>
To: "GCC-XML Discussion" <gccxml at public.kitware.com>
Sent: Tuesday, March 12, 2002 5:05 PM
Subject: [GCC-XML]Re-write prototype in CVS


> Hello, all:
>
> I have finally found enough time to finish off the first version of
> the re-write of GCC-XML.  The new version has been committed to the
> main branch of the CVS repository.  A new GCC patch has been provided
> that should work with GCC 3.0.4.

Cool!

> The version of GCC-XML that existed prior to this checkin has been
> branched from the main tree.  Anyone who still wants to use that
> version should do
>
>   cvs update -r declaration-style
>
> to move over to the branch.
>
> Output from the new version is almost completely different from
> previous versions, and is not at all backward-compatible.  It is
> organized as a set of nodes in a graph.  Each node has an id that can
> be referenced by other nodes, and is dumped as its own XML element.
> There is no nesting of XML elements because nesting reflects a tree
> structure, not a graph.

A parse tree is, well, a tree... so why would nesting be inappropriate?
I don't know much about XML, but I'm under the impression there are ways
to produce cross-references in an XML tree, resulting in an arbitrary
graph.

> This is the first version of GCC-XML to support partial dumps.  There
> is a new option that allows specification of where to start:
>
> gccxml ... -fxml=output.xml -fxml-start=myClass,foo::bar input.cxx
>
> The argument to -fxml-start is a comma-separated list of start
> locations.  Each location can be a qualified name starting at the
> global namespace.  If the option is not given, the whole global
> namespace is dumped.  No template or function arguments are allowed.
> To gain exact control over the start locations, one can always write a
> dummy function whose arguments are the types to be dumped.  Specifying
> the name of this function with -fxml-start will begin the dump there.

Hmm, how about just making file/line available as an interface? I
presume that information is still around by the time your backend gets
ahold of the AST (or how would anyone write debuggers?)

> The new implementation has not been extensively tested, so I suggest
> configuring the patched GCC with --enable-checking to get errors
> instead of seg-faults if something goes wrong.
>
> For anyone who tries this out, I welcome comments on the new dump
> format.  It is not written in stone.  You will probably notice that
> the output is significantly smaller, especially if the -fxml-start
> option is used.  The output is less human-readable (in my opinion),
> but is much better for parsing and for use by a program.

Any chance you could post a sample somewhere, so I could get a sense for
the new output without having to build the whole project?

This is a very interesting coincidence, considering this post in a
related project:

http://sourceforge.net/mailarchive/message.php?msg_id=1302145

See also my reply at:

http://sourceforge.net/mailarchive/message.php?msg_id=1302576

It would be great if these two projects developed some synergy. It would
be interesting to write the interface glue between gcc-XML and synopsis
in Python.

-Dave





More information about the gccxml mailing list