Re: [RFA] Limited DW_OP_piece support

[Kevin Buettner <kevinb@redhat.com>]

On May 22,  5:29pm, Daniel Jacobowitz wrote:

> On Thu, May 22, 2003 at 02:19:31PM -0700, Kevin Buettner wrote:
> > On May 22,  2:19pm, Daniel Jacobowitz wrote:
> > 
> > > On Thu, May 22, 2003 at 10:00:39AM -0700, Kevin Buettner wrote:
> > > > The patch below adds limited DW_OP_piece support to dwarf2expr.c.  I
> > > > will post a patch to rs6000-tdep.c which illustrates what a
> > > > ``dwarf2_compose_register_pieces'' method should look like.
> > > > 
> > > > Okay?
> > > 
> > > I would really strongly prefer that we not do it this way.
> > > 
> > > You'll notice that there are no other gdbarch calls in the expression
> > > evaluator.  There might be some implicit ones through macros, for
> > > instance there is TARGET_ADDR_BIT.  That needs to be fixed properly
> > > some day already.
> > > 
> > > Instead, IMHO, we should devise a way to represent multiple locations
> > > in the evaluator's return value.  This is not suggesting the complete
> > > overhaul that we need to support multiple locations in the rest of GDB.
> > > Then have the expression evaluator properly return a list of locations,
> > > and have the massaging done via gdbarch in the evaluator's client. 
> > > Does that sound reasonable?
> > 
> > I must admit that it sure sounded reasonable when I first read it. 
> > I've been looking at the code to see how doable it is, and it's
> > looking less reasonable to me now.  It appears to me that there are
> > multiple clients and it seems ugly to do the massaging that you speak
> > of in multiple places.  (Or perhaps I misunderstand who the client
> > is?)
> 
> I'm suggesting that the massaging be done in the caller of
> dwarf_expr_eval.  There are three of them at present: one which only
> cares about whether we need a frame, and two for locations.  One's the
> frame base, and the other's via dwarf2_evaluate_loc_desc.
> 
> For the moment, I believe everything you need could be done in
> dwarf2_evaluate_loc_desc.  The frame base will not (on current
> platforms, etc.) use DW_OP_piece, and that call should be going away
> anyway.  There will be more calls, as we use the evaluator for more,
> but it's not clear how they should react to DW_OP_piece.
> 
> Another alternative is to do it in dwarf_expr_eval.  This would
> probably want us to separate it into two functions: one for evaluating
> an expression as a location, and one otherwise.  i.e. there are times
> when DW_OP_piece should be handled, and times when it is not valid. 
> They can have different return signatures.
> 
> Does that make more sense?

Yeah.  I was going too far up the stack.

Thanks,

Kevin