This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: DW_OP_piece coming in gcc 3.4
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