Re: a value has-a location

[Andrew Cagney <cagney at gnu dot org>]

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