Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch]

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Aug 04, 2004 at 05:19:30PM -0500, Jim Blandy wrote:
> Well, in the immediate term, dwarf2loc.c should simply reject
> locations with pieces, and generate an error message.  This is the
> same behavior we have now, but instead of dwarf2expr.c saying
> "Unrecognized opcode 0x93", dwarf2loc.c can say something more
> informative like "The value of variable 'foo' is distributed across
> several locations, and GDB cannot access its value."
> 
> The next step is to have something that will recognize when a series
> of pieces is actually a reference to a single register --- presumably
> one that GDB has a number for, but one that Dwarf only has numbers for
> pieces of.  That needs to be an arch method that recognizes the cases
> that can be simplified, and passes on the cases it can't handle.  This
> will address all the current uses of DW_OP_piece, I believe.

No, it won't.  GCC already generates more than that.

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.

> In the long run, it's just as you said: there should be some kind of
> 'struct location' that 'struct value' can refer to, and that things
> like value_fetch_lazy and value_assign understand and operate on.  I
> don't have a lot of insight into how that all ought to fit together.
> But I don't think that affects the form of the best interface to
> dwarf2expr.c: that should simply provide all the information it has,
> and leave it to the caller to decide what to do with it.

This just means auditing every site that references a memory variable's
"address" and making them either fail (conservative) or use some helper
which understands a list of pieces.  There's a large number, but most
of them are trivial.  I don't think it will really take very long to
do, on the GDB timescale.

-- 
Daniel Jacobowitz