From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13805 invoked by alias); 22 May 2003 21:42:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13780 invoked from network); 22 May 2003 21:42:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 May 2003 21:42:29 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4MLgTH20158 for ; Thu, 22 May 2003 17:42:29 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4MLgTI19891; Thu, 22 May 2003 17:42:29 -0400 Received: from localhost.localdomain (vpn50-3.rdu.redhat.com [172.16.50.3]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4MLgSo31162; Thu, 22 May 2003 17:42:28 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h4MLgNx31428; Thu, 22 May 2003 14:42:23 -0700 Date: Thu, 22 May 2003 21:42:00 -0000 From: Kevin Buettner Message-Id: <1030522214223.ZM31427@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: [RFA] Limited DW_OP_piece support" (May 22, 5:29pm) References: <1030522170039.ZM30271@localhost.localdomain> <20030522181932.GA31074@nevyn.them.org> <1030522211930.ZM31332@localhost.localdomain> <20030522212925.GA16777@nevyn.them.org> To: Daniel Jacobowitz , Kevin Buettner Subject: Re: [RFA] Limited DW_OP_piece support Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00442.txt.bz2 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