* a value has-a location
@ 2004-11-02 15:14 Andrew Cagney
2004-11-02 15:32 ` Joel Brobecker
2005-02-07 20:17 ` Andrew Cagney
0 siblings, 2 replies; 3+ messages in thread
From: Andrew Cagney @ 2004-11-02 15:14 UTC (permalink / raw)
To: gdb
(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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: a value has-a location
2004-11-02 15:14 a value has-a location Andrew Cagney
@ 2004-11-02 15:32 ` Joel Brobecker
2005-02-07 20:17 ` Andrew Cagney
1 sibling, 0 replies; 3+ messages in thread
From: Joel Brobecker @ 2004-11-02 15:32 UTC (permalink / raw)
To: Andrew Cagney; +Cc: gdb
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: a value has-a location
2004-11-02 15:14 a value has-a location Andrew Cagney
2004-11-02 15:32 ` Joel Brobecker
@ 2005-02-07 20:17 ` Andrew Cagney
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2005-02-07 20:17 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-02-07 20:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-02 15:14 a value has-a location Andrew Cagney
2004-11-02 15:32 ` Joel Brobecker
2005-02-07 20:17 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).