Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions

[Andrew Cagney <ac131313@cygnus.com>]

>> GDB has, well almost has, a byte code interpreter it 100%
>> controls. Jim, remember tracepoints?
> 
> 
> Uggggh.
> I've already sent an implementation of one we would 100% control, that
> is easy for debug formats to convert into, and easy for us to
> evaluate.


Yes, that makes two implementations.


> It would also be trivial to use it *as* the agent bytecode if you
> wanted to.   I don't think the agent bytecode, however, should be used
> as our symbol location language.  It just doesn't seem to fit well at
> all in terms of interface, it's original purpose, etc.


That wouldn't fly.  The agent bytecode is documented and published and a 
sample implementation is somewhere.


> We seem to have a problem in GDB with shoe horning things to fit where
> they don't.



>> To initially set the bar very high (I'm sure it will soon come
>> crashing down) the byte code interpreter should to be implemented as a
>> true state machine. 
>> This is significant - instead of assuming that
>> target_read() returns the data immediatly, it should instead be
>> designed to allow for the day when target_read() returns ERETRY.
>> 
> 
> We are trying to replace the way locations are described now with
> something that is more expressive.  Not change the fundamentals of how
> locations work.
> We still, besides getting symeval approved, eventually have to replace
> all the current uses for the  different locations with just this one
> type of location type (IE get rid of LOCATION_BASE_REG, etc, in favor
> of the bytecoded form). This is in itself, at least 6 months minimum
> (because of how far reaching a  change it will be). Then we can worry
> about merging the tracepoint stuff and the location evaluation 
> stuff.
> Doing that right now would make making this an incremental change much
> harder.  Right now, symeval requires no changes to other parts of
> gdb.  Zero. Everything that worked before keeps working.   We can
> incrementally change the symbol readers to start using it.
> Then we can incrementally change the reader to not depend on always
> having the value actually there.
> Etc.


Ah, Ok.

Hmm, a reader not depending on always having the value actually there 
would mean having partially evaluated expressions around.

Andrew