From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1064 invoked by alias); 22 May 2003 21:21:38 -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 29202 invoked from network); 22 May 2003 21:19:37 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 May 2003 21:19:37 -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 h4MLJbH13912 for ; Thu, 22 May 2003 17:19:37 -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 h4MLJbI11748; Thu, 22 May 2003 17:19:37 -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 h4MLJao28969; Thu, 22 May 2003 17:19:36 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h4MLJVa31333; Thu, 22 May 2003 14:19:31 -0700 Date: Thu, 22 May 2003 21:21:00 -0000 From: Kevin Buettner Message-Id: <1030522211930.ZM31332@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: [RFA] Limited DW_OP_piece support" (May 22, 2:19pm) References: <1030522170039.ZM30271@localhost.localdomain> <20030522181932.GA31074@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/msg00440.txt.bz2 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 don't want to argue too vigorously for the limited DW_OP_piece patch that I submitted because I agree that it'd be better to have it implemented in a more generic manner. The one thing that my patch does have going for it though is that, aside from the addition of the gdbarch method and the architecture dependent support, it consists solely of the addition of one case to a switch statement. This makes it very easy to back out when we finally do things "right". Simply delete that case (and the gdbarch method) and it's out. I'd even be willing to add some comments and possibly an ifdef to that case to further delimit it from the rest of the code. The comments would make it clear that this is a stopgap measure that will eventually be removed and would describe precisely how to remove it. Kevin