a value has-a location

a value has-a location

[Andrew Cagney]

(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

Re: a value has-a location

[Joel Brobecker]

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

Looks good. I didn't comment on making struct value opaque, but I think
it's a terrific idea. I think we should be doing the same for struct
type, and possible struct symbol/minimal_symbol/partial_symbol as well.
And heck, we could do the same for the symtab structs as well. That
would probably help us with transforming the low/high address range
into a set of ranges, for the compilation units that are not contiguous
in memory (a long term project of mine).

-- 
Joel

Re: a value has-a location

[Andrew Cagney]

Andrew Cagney wrote:
> (back to this one again)
> 
> We've the relationship:
> 
>        LOCATION ----<> VALUE <>----- TYPE
>            .
>           /_\
>            |
>            +-------------------------.
>            |                         |
>      DWARF-2 LOCATION         LEGACY LOCATION

Now that I've got "struct value" more or less under control, I've 
sufficient information to expand refine this.  First the above becomes:

         TYPE -----<> VALUE <>----- CONTENT

i.e.: VALUE has-a TYPE; VALUE has-a CONTENT

When it comes to CONTENT, that can be further refined:

                 1      N
         CONTENT <>------ PIECE
            <>
             \
              `---- BUFFER

i.e., CONTENT has-a 1:N PIECE; CONTENT has-a BUFFER.

So what was LOCATION has been expanded into CONTENT (rough 
correspondence to the existing value->contents) and PIECE (rough 
correspondence to DW_OP_piece).

Looking at the code, the existing VALUE fields, dependent on whether 
they make up part of the content (e.g., value->contents) or the 
content's location (aka piece) (e.g., value->lval), need to be moved to 
either CONTENT or PIECE.  For fields moved to CONTENT, things are 
straight forward:

Old:	value->aligner.contents
New:	value->contents->buffer

Old:	value->lazy
New:	value->contents->lazy

However, for the VALUE fields that describe the actual location (i.e., 
PIECE) there's a problem - there are now N PIECEs.  Initially I'll 
assume there's only one piece giving:

Old:	value->lval
Hack:	value->contents->piece[0]->lval

(the assume-one-piece methods will be DEPRECATED).  Going forward the 
code can be updated to eliminate that assumption, instead iterating over 
multiple pieces.

Andrew