This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

a value has-a location


(back to this one again)

We've the relationship:

       LOCATION ----<> VALUE <>----- TYPE
           .
          /_\
           |
           +-------------------------.
           |                         |
     DWARF-2 LOCATION         LEGACY LOCATION

That is:

A VALUE has-a TYPE and a LOCATION. The LOCATION describing how to obtain the BITS and BYTES belonging to the value (but may not actually contan those bits and bytes).

LOCATION could have methods such as:

	int read (offset, length, readbuf)
	    -- read at least some of the bytes
	void read_full (offset, length, writebuf)
	    -- read all the bytes, or throw an error
	int io (offset, length, readbuf, writebuf)

and perhaphs:

	iterate-over-pieces (method)
	    -- call method with each register/memory piece
	    -- needed by watchpoints

A DWARF-2 LOCATION would be implemented using the DWARF-2 code. A LEGACY LOCATION would accomodate the old more explicit way of doing things.

It is this that will replace VALUE_CONTENTS{,_RAW} et.al.

I intend refactoring ``struct value'' so that there is an explicit location object (at present it's a union :-/). Initially it will probably remain in ``struct value''. Once the location has been separated out we can look at making it virtual with separate dwarf-2 and legacy locations.

comments?
Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]