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

[Daniel Berlin <dan at cgsoftware dot com>]

Andrew Cagney <ac131313@cygnus.com> writes:

> Two things:
> 
> 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.

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.

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

Look at struct type's target_type, and tell me if you don't think it
came about because someone thought "I know, let's just reuse this
thing that is somewhat related but not really".


> 
> 
> 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.


> 
> Hmm, no, I lied, three things :-)
> 
> To follow up Jim's comment about GDB 100% controlling the byte code
> interpreter. 
I don't think anyone is unhappy with the current symeval I posted,
except in the interface.
IE The 100% control issue seems to be resovled.
>  Am I correct to think that, for tracepoints to continue
> working, GDB will need to translate DWARF2 bytecode expressions into
> tracepoint expressions so that they can be run on the target when
> fetching variables?

It'll need to translate GDB location expressions (they are different
than the dwarf2 bytecode expressions in subtle ways, and have
different opcode numbers anyway.) into tracepoint expressions.

However, It would actually be easier on the tracepoint expression code
eventually.

Right now, it has to handle all of the location types differently.





> 
> 
> 	Andrew

-- 
"I play the harmonica.  The only way I can play is if I get my
car going really fast, and stick it out the window.  I've been
arrested three times for practicing.
"-Steven Wright