Re: [PATCH v2] Replace the symbol needs evaluator with a parser

[Tom Tromey <tom@tromey.com>]

>>>>> "Zoran" == Zoran Zaric <Zoran.Zaric@amd.com> writes:

Zoran> The problem here is that faking results of target interactions can yield
Zoran> an incorrect evaluation result.

...

Zoran> This is clearly a wrong result and it causes the debugger to crash.

Zoran> +      /* The DWARF expression might have a bug causing an infinite
Zoran> +	 loop.  In that case, quitting is the only way out.  */
Zoran> +      QUIT;

Can this really occur in this scanner?

For evaluation I can understand it, but this scanner seems to just walk
the bytecode once, so I don't see how it is possible.

For gimli (again) we have a maximum operation count to avoid this kind
of problem.  gdb could do this as well.

Meanwhile, about the linear scan -- it seems to me that nothing in DWARF
requires (1) that the expression not contain embedded garbage, and (2)
that it not be possible to branch to the middle of some other
instruction.  (If there is text along these lines, I'd like to hear
about it; I looked in the past and couldn't find it.)

This is pathological, of course.  But on the other hand, if the
motivation is to avoid crashes, it seems bad to, say, let this function
pass through some bytecode that would then be interpreted a different
way by the actual evaluator.

Personally I'd be fine with rejecting this bad stuff from the evaluator
as well.  But anyway the difficulty is that they have to be in sync, and
aren't.

Another approach would be to record which offsets are branched to; and
to pop from such a list when an unconditional branch is encountered.
This would solve both problems as well.

Tom