This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Andrew Cagney <cagney@gnu.org> writes:

> > Andrew Cagney <cagney@gnu.org> writes:
> >
> >>>> > Andrew Cagney <cagney@gnu.org> writes:
> >>>> >
> >>>
> >>>>>> >>> I'm just having trouble getting my head around how this will affect
> >>>>>> >>> core-gdb, and seeing how this addresses our need to meet GCC 3.5's
> >>>>>> >>> requirements?
> >>>>>> >>> Can we expand on that?
> >>
> >>> ?
> > I answered this.  The dwarf2.expr.h change I posted doesn't get into
> > GCC 3.5's requirements, and it shouldn't.  It's just meant to allow
> > dwarf2expr.[ch] to return the results of the computation it did; it's
> > up to its caller what to do with that.
> 
> Ok.  Can we just expand a little on how/where the caller, core-gdb,
> will use this then?

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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]