[Bug breakpoints/7253] Asynchronous expression evaluator

[Bug breakpoints/7253] Asynchronous expression evaluator

[tromey at redhat dot com]

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.

[Bug breakpoints/7253] Asynchronous expression evaluator

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=7253

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
That previous comment is mostly obsolete since expressions have
been rewritten to be ordinary objects and not that weird data
structure.

This rewrite made it harder to make this code async.
It could be done by rewriting each evaluator to be a state
machine of some kind.  This might more easily be done
with C++20, though of course gdb won't switch to that for
a decade or more.

-- 
You are receiving this mail because:
You are on the CC list for the bug.