This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug breakpoints/7253] Asynchronous expression evaluator
- From: "tromey at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sun, 29 Dec 2013 10:09:24 +0000
- Subject: [Bug breakpoints/7253] Asynchronous expression evaluator
- Auto-submitted: auto-generated
- References: <bug-7253-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=7253
Tom Tromey <tromey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com
--- Comment #1 from Tom Tromey <tromey at redhat dot com> ---
I looked into this a bit and figured I would write down what I found.
First, expressions are represented very poorly in gdb. However,
changing the representation is also very difficult. I chose to
examine an approach that keeps the expression representation as-is.
First, with not much work it is possible to split the main function
in eval.c into a number of smaller functions, one per opcode.
My exploratory hack did this in a heavily macroized way both to
enable subsequent steps and also to avoid a lot of typing.
This split was easily done with a keyboard macro in emacs.
Then a new "state" argument can be added to the functions (via
the macro introducing each one...). The idea is to turn each
function into a little state machine -- at any point where an
opcode implementation would normally recurse, it instead returns
NULL (perhaps setting some output flags in the state). The
evaluator main loop recognizes this result specially, pushes
its state on an explicit stack, and then loops.
I stopped toying somewhere in the middle of this step. I believe
the remaining steps are:
* Complete the conversion of each such function into a state machine.
* Apply this transform to the various language overrides as well.
* Finish rewriting the outermost expression parser to use the
state machine approach. At this point it should be clear that any
expression evaluation can be paused in the middle and then restarted,
as all state is explicitly maintained.
* Update the state machine code to allow a function call to in fact
be paused.
* Convert the value_x_* functions to return the function they find,
and have the caller invoke call_function_by_hand. This exposes
a currently hidden inferior call.
* Audit the current code for hidden calls to coerce a value to target
memory. This involves an inferior call so for best results it should
be explicitly handled by the various state machine functions.
It seems that it is probably ok if some more obscure calls are not
converted, or at least not immediately.
* Convert call_function_by_hand (see the "SNIP SNIP" comment) to work
asynchronously. Add a new expression-evaluation entry point that
handles this properly.
* Then propagate the "continuation passing conversion" upward into
callers of the expression evaluator as appropriate. Probably the
most important one is breakpoint condition evaluation.
It's still unclear to me whether this is worth the effort involved.
I'm also unclear on what exactly is required in the last step mentioned
above.
--
You are receiving this mail because:
You are on the CC list for the bug.