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