From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4727 invoked by alias); 4 Aug 2004 22:22:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4720 invoked from network); 4 Aug 2004 22:22:03 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Aug 2004 22:22:03 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i74MM3e1003416 for ; Wed, 4 Aug 2004 18:22:03 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i74MM1a31387; Wed, 4 Aug 2004 18:22:01 -0400 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch] References: <4111145F.7000504@gnu.org> <41112BAE.9080304@gnu.org> <41115B4F.1080700@gnu.org> From: Jim Blandy Date: Wed, 04 Aug 2004 22:22:00 -0000 In-Reply-To: <41115B4F.1080700@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg00049.txt.bz2 Andrew Cagney writes: > > Andrew Cagney writes: > > > >>>> > Andrew Cagney 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.