From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3180 invoked by alias); 4 Aug 2004 23:17:16 -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 3162 invoked from network); 4 Aug 2004 23:17:15 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Aug 2004 23:17:15 -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 i74NHFe1014225 for ; Wed, 4 Aug 2004 19:17:15 -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 i74NHDa13811; Wed, 4 Aug 2004 19:17:13 -0400 To: Daniel Jacobowitz Cc: Andrew Cagney , 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> <20040804230242.GA10332@nevyn.them.org> From: Jim Blandy Date: Wed, 04 Aug 2004 23:17:00 -0000 In-Reply-To: <20040804230242.GA10332@nevyn.them.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/msg00055.txt.bz2 Daniel Jacobowitz writes: > On Wed, Aug 04, 2004 at 05:19:30PM -0500, Jim Blandy wrote: > > 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. > > No, it won't. GCC already generates more than that. Okay --- that's good to know. > I'm dubious as to whether this step is even worthwhile. Another > possible intermediate step is to immediately combine the pieces, > marking the value as not_lval; read them all and piece them together in > GDB's memory. Yes, this means that they can't be assigned to, but at > least we'd be able to inspect them. It seems worthwhile to me, because it will allow GDB to work correctly, assignments and all, in the cases where the current value structures can handle it, and it's very little work. At some point, resources will materialize to do the larger project, but what's the harm in getting the best behavior we can out of the current structures until then?