Re: implementing full scattered values

[Andrew Cagney <cagney at gnu dot org>]

It's good to see that the arch changes have been taken off the table.

> Last month there was a thread on supporting DW_OP_piece:
>
>     http://sources.redhat.com/ml/gdb/2004-08/msg00004.html
>
> Everyone agreed that having architecture-independent support for
> arbitrary DW_OP_piece location expressions would be preferable to the
> partial and architecture-dependent support, if someone could find time
> to do it soon.
>
> Let's talk about full scattered value support.  What's the best
> approach?  What's entailed?  How do we want 'struct value' to look
> when we're done?  Let's try to set some concrete goals so that if
> someone does have the cycles to work on this, they can have some idea
> what to work towards so it'll be acceptable for inclusion in the
> public sources.

Daniel at the time wrote:

> I'm dubious as to whether this step is even worthwhile.  Another
> possible intermediate step is to immediately combine the pieces,
> marking the value as not_lval; read them all and piece them together in
> GDB's memory.  Yes, this means that they can't be assigned to, but at
> least we'd be able to inspect them.

I think this idea needs to be explored.

Up until now we've all been assuming that we had to implement:

	``struct value'' has-a array-of ``struct location''

yet what we should really be implementing is:

	``struct dwarf-2-value'' is-a ``struct value''

where ``struct value'' has a small number of virtual methods that let 
GDB both read and write the value's underlying bytes.

I guess this means lval_expression, with the other lval's being 
deprecated.  We've already kind of got this with symbols (although the 
old code was never deprecated / flushed).

--

Anyway, before we even start persuing this, I think we should drain our 
existing backlog of debuginfo patches, hopefully in time for 6.3.

Andrew