From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17705 invoked by alias); 22 May 2003 21:29:42 -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 17681 invoked from network); 22 May 2003 21:29:41 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 22 May 2003 21:29:41 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19Ixda-0002jM-00; Thu, 22 May 2003 16:30:10 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19Ixct-0004O7-00; Thu, 22 May 2003 17:29:27 -0400 Date: Thu, 22 May 2003 21:29:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Limited DW_OP_piece support Message-ID: <20030522212925.GA16777@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <1030522170039.ZM30271@localhost.localdomain> <20030522181932.GA31074@nevyn.them.org> <1030522211930.ZM31332@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1030522211930.ZM31332@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00441.txt.bz2 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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer