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

["Zaric, Zoran (Zare)" <Zoran.Zaric@amd.com>]

[AMD Official Use Only - Internal Distribution Only]

Thank you for looking at my patch Tom.

I realize that I am new here and that might make some reviewers
a bit reserved.

> From: Tom Tromey <tom@tromey.com>

> One question I have here is whether we even need this symbol-needs-frame
> stuff.  What if, instead, we just had gdb throw an exception in the situation
> where a frame is needed but not available?  Then we could get rid of the
> asserts and gdb would simply print an error rather than crash.
> 
> Can you look to see if that is feasible?  The main advantage I see here is that
> this approach would avoid the problem we sometimes have of updating one
> DWARF expression-decoder and then forgetting to update the others...

I've spoken with Pedro Alves and Simon Marchi about this and the difficulty
here is that both "python" and "scheme" interfaces expose this functionality
to the user. 

Another concern is that symbol_read_needs check is sometimes used as an
optimization of sorts to determine if the lexical block for a given symbol
needs to be tracked or not.

My fear is that replacing all of these use cases with a call to the full
evaluator would be unacceptable overhead.

That being said, I am currently working on a patch series that I am
planning to submit soon. 

The idea is to change the design of the DWARF expression evaluator
so that it throws an exception based on a context requirements  of
a given operation.

Without going to much into details here, this new approach will
remove certain context restrictions that currently exist for standard
DWARF (like using composite location description in CFI) and allow 
implementation of future DWARF extensions for better support  of
optimized code debugging. More on this work can be found here:

https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html

In the same way, this new implementation can be used to remove the
symbol-needs-frame stuff, if we decide that the benefit of having this
check (instead of full-fledged evaluation) is not important.

> What I did in gimli is have a parser that converts the DWARF expression to an
> internal form.  Then users of the API can decide how to manipulate this form
> -- dump it, evaluate it, etc.  This separates the low-level parsing bits from the
> decisions about what operations to perform.

I like this approach, but it does require a bit more analysis of the existing
DWARF handling infrastructure, because at the moment it is all over the place.

Thanks,
Zoran