From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Add support for tracking/evaluating dwarf2 location expressions Date: Wed, 06 Jun 2001 09:46:00 -0000 Message-id: <878zj5r1y1.fsf@cgsoftware.com> References: <3B1E4DCC.2090607@cygnus.com> X-SW-Source: 2001-06/msg00075.html Andrew Cagney 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