This is the mail archive of the
mailing list for the Archer project.
Expression Parser Plug-In Available
- From: Keith Seitz <keiths at redhat dot com>
- To: archer at sourceware dot org
- Date: Thu, 10 Mar 2011 12:46:20 -0800
- Subject: Expression Parser Plug-In Available
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
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
<var_decl 0x7fbb4d008aa0 command
type <pointer_type 0x7fbb4da115e8
type <record_type 0x7fbb4da0d690 cmd_list_element VOID
align 8 symtab 0 alias set -1 canonical type 0x7fbb4da0d690
pointer_to_this <pointer_type 0x7fbb4da115e8> chain
<type_decl 0x7fbb4da057e8 D.10095>>
size <integer_cst 0x7fbb4dfb67a8 constant 64>
unit size <integer_cst 0x7fbb4dfb67d0 constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7fbb4da115e8
pointer_to_this <pointer_type 0x7fbb4d824348>>
used unsigned DI file ../../src/gdb/breakpoint.c line 11987 col 28
size <integer_cst 0x7fbb4dfb67a8 64> unit size <integer_cst
align 64 context <function_decl 0x7fbb4d294c00 add_catch_command>>
time in evaluating in-line expression: 0.308954 (99%)
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
<var_decl 0x7fddb1dd3280 catMan
type <record_type 0x7fddb3084150 nsCOMPtr addressable asm_written
needs-constructing type_1 type_4 type_5 type_6 BLK
size <integer_cst 0x7fddbb7827a8 constant 64>
unit size <integer_cst 0x7fddbb7827d0 constant 8>
align 64 symtab -1310826496 alias set -1 canonical type
fields <field_decl 0x7fddb1dd2720 mRawPtr type <pointer_type
private unsigned nonlocal decl_3 DI file
../../../dist/include/nsCOMPtr.h line 522 col 10 size <integer_cst
0x7fddbb7827a8 64> unit size <integer_cst 0x7fddbb7827d0 8>
align 64 offset_align 128
offset <integer_cst 0x7fddbb782410 constant 0>
bit offset <integer_cst 0x7fddbb782f28 constant 0> context
<record_type 0x7fddb3084150 nsCOMPtr> chain <type_decl 0x7fddb1dcba10
nsCOMPtr>> context <translation_unit_decl 0x7fddbb78e958 D.1>
full-name "class nsCOMPtr<nsICategoryManager>"
needs-constructor needs-destructor X() has-type-conversion
X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown
pointer_to_this <pointer_type 0x7fddb30842a0> reference_to_this
<reference_type 0x7fddb3088d20> chain <type_decl 0x7fddb1dcb958 nsCOMPtr>>
addressable used tree_1 tree_3 decl_5 BLK file
6433 col 32 size <integer_cst 0x7fddbb7827a8 64> unit size <integer_cst
align 64 context <function_decl 0x7fddb6981200
time in evaluating in-line expression: 5.395179 (100%)
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!