Re: DW_OP_piece coming in gcc 3.4

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jan 29, 2004 at 10:51:53PM -0700, Kevin Buettner wrote:
> On Fri, 30 Jan 2004 00:27:57 -0500 (EST)
> mec.gnu@mindspring.com (Michael Elizabeth Chastain) wrote:
> 
> > I'm getting this with gcc-3_4-branch -gdwarf-2:
> > 
> >   (gdb) PASS: gdb.base/store.exp: up print old l - longest
> >   print r^M
> >   Unhandled dwarf expression opcode 0x93^M
> >   (gdb) FAIL: gdb.base/store.exp: up print old r - longest
> > 
> > We need a strategic decision:
> > 
> > (1) Implement DW_OP_piece in time for gdb 6.1.
> > (2) Ask gcc to not emit DW_OP_piece in gcc 3.4.
> > (3) File a PR (or tag onto PR gdb/1312 but that's not really right),
> >     KFAIL the tests, add a note to PROBLEMS.
> > 
> > I don't know which strategy is good for gdb.
> > 
> > What will it be?
> 
> The "right" thing is to get DW_OP_piece support into gdb (#1).  I'm
> firmly against #2.  #3 may be an acceptable as a short term solution,
> but I'm none too fond of it either.
> 
> So, I vote for #1.

I agree.  I think that adding it to LOC_COMPUTED, especially in an
initial form that does not allow changing piecewise values (not_lval)
will be pretty simple.  Adding it as a first-class citizen all over GDB
is a little trickier, since it means checking every use of
SYMBOL_VALUE_ADDRESS on non-minsyms.

One cleanup I've been meaning to do for ages, but not had time, is to
break SYMBOL_VALUE_ADDRESS into three macros.  One for minimal symbols,
one for partial symbols, and one for full symbols.  That would let us
get a much better feel for the scope of the problem.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer