implementing full scattered values

implementing full scattered values

[Jim Blandy]

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.

Re: implementing full scattered values

[Andrew Cagney]

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