From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2084 invoked by alias); 10 Mar 2011 20:46:30 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2074 invoked by uid 22791); 10 Mar 2011 20:46:28 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_DB,TW_DF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Message-ID: <4D79389C.7050500@redhat.com> Date: Thu, 10 Mar 2011 20:46:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: archer@sourceware.org Subject: Expression Parser Plug-In Available Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2011-q1/txt/msg00122.txt.bz2 Hi, all, In October, we discussed writing a compiler plug-in to play/experiment with the possibility of re-using the compiler's parsers for gdb. Well, at long last, I have checked-in an initial version of the plug-in to do this. I'm sure someone more familiar with the compiler will find a bunch of problems and/or refinements to be made, but this should be a start. You can grab the sources from gcc's git repository. The plug-in is on the archer-expr-plugin branch. The README (archer-expr-plugin/README) explains how to build and play with this thing. Right now, the plug-in is attempting to suppress errors and warnings. I've attempted to install a minimal diagnostic pretty-printer which does nothing, but I haven't quite got it right yet; it will/might crash if the expression produces a fatal error. Not nice, but good enough for now. I'll try to fix this as time permits and demand dictates. The plug-in uses debug_tree to output the result of the parse. I'm sure this is too verbose to be useful, or at least optimal, but again, probably good enough for playing around. I should mention: the plug-in could probably be optimized a bit. I had to resort to some expensive location expansion and strcmp'ing filename basenames... In the little playing around that I've done, this hasn't really been as big an issue as I would have thought, though, but I thought it worth mentioning. Here are the two tests I've been using. One is parsing an expression (just a local variable) in a function near the end of breakpoint.c. The other is something similar in a firefox source file: Parse "command" at breakpoint.c:11990: $ sh ~/compile-breakpoint.o chain > unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7fbb4da115e8 pointer_to_this > used unsigned DI file ../../src/gdb/breakpoint.c line 11987 col 28 size unit size align 64 context > time in evaluating in-line expression: 0.308954 (99%) real 0m0.329s user 0m0.306s sys 0m0.019s The phrase "in-line expression" means that the expression was parsed at the location given by the input. [If parsing fails here, the plug-in will continue until the end of the file and try again. In that case, it says "at exit".] Parse "catMan" in mozilla/content/base/src/nsContentUtils.cpp:6437: $ sh ~/compile-firefox unit size align 64 symtab -1310826496 alias set -1 canonical type 0x7fddb3084150 fields private unsigned nonlocal decl_3 DI file ../../../dist/include/nsCOMPtr.h line 522 col 10 size unit size align 64 offset_align 128 offset bit offset context chain > context full-name "class nsCOMPtr" needs-constructor needs-destructor X() has-type-conversion X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this chain > addressable used tree_1 tree_3 decl_5 BLK file ../../../../mozilla-central/content/base/src/nsContentUtils.cpp line 6433 col 32 size unit size align 64 context > time in evaluating in-line expression: 5.395179 (100%) real 0m12.356s user 0m5.123s sys 0m0.297s As you can see, there is a substantial difference between the shell and the plug-in times in this test case. I haven't investigated this a whole lot, but by using -ftime-report, the majority of this time is spent in "parsing", "garbage collection", and "name lookup". The plug-in measures time from the end of plug-in initialization to the outputting of the parse tree. I'll investigate further. Comments/advice/suggestions -- please send them along! Keith