From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11743 invoked by alias); 19 Oct 2002 03:28:56 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11680 invoked from network); 19 Oct 2002 03:28:55 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 19 Oct 2002 03:28:55 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 182kIJ-0003aL-00 for gcc@gnu.org; Fri, 18 Oct 2002 23:28:55 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 182kIG-0003cx-00 for gcc@gnu.org; Fri, 18 Oct 2002 23:28:53 -0400 Received: from egil.codesourcery.com ([66.92.14.122]) by monty-python.gnu.org with esmtp (Exim 4.10) id 182kIG-0003cJ-00 for gcc@gnu.org; Fri, 18 Oct 2002 23:28:52 -0400 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 182kIE-000857-00; Fri, 18 Oct 2002 20:28:50 -0700 Date: Sat, 19 Oct 2002 04:31:00 -0000 To: James Michael DuPont Cc: Joe Buck , Joe Buck , gcc@gnu.org Subject: Re: XML dumping and GraphViz/VCG in the GCC ast-optimizer-branch Message-ID: <20021019032849.GC24290@codesourcery.com> References: <200210151719.g9FHJ8c20233@piper.synopsys.com> <20021015180452.73666.qmail@web13303.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021015180452.73666.qmail@web13303.mail.yahoo.com> User-Agent: Mutt/1.4i From: Zack Weinberg X-Spam-Status: No, hits=-14.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: X-SW-Source: 2002-10/txt/msg01179.txt.bz2 On Tue, Oct 15, 2002 at 11:04:52AM -0700, James Michael DuPont wrote: > Now, if we look at the problem of communication, how can the gcc safely > communicate the asts to the vcg for layout. > > You will see that any form of communcation is subject to a > man-in-the-middle attack that can dump the data out to a pipe. > > Now you also need the ability to focus the results on something > visible, to search and filter the ast nodes. Others will want to > transform the trees selecting certain attributes and turning those > into graph nodes. > > If the asts are put into an libxml dom structure, those transformations > can be done by a simple xslt style sheet, or perl script linked in, and > the passed on to the visualizer, all without leaving main memory. > > So you see that to do anything usefull with this information, it must > run the risk to be intercepted. This is silly. The relevant policy goal of the FSF in this context is to prevent people from writing front ends, optimization modules, or back ends for GCC which are not free software. Rendering the AST, or the CFG, or whatever, in a form suitable for graphing will not facilitate any of these goals. In fact, we already *have* code to generate VCG graphs from the debugging dumps. So just write your graph to a file in whatever format seems sensible to you. (We are unlikely to take the patch if it is a format readable only by proprietary software, but then until just now that was true of the existing graph dumper.) zw