From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29373 invoked by alias); 4 Aug 2004 23:04:21 -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 29353 invoked from network); 4 Aug 2004 23:04:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Aug 2004 23:04:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BsUmQ-0007rF-Sl; Wed, 04 Aug 2004 19:02:43 -0400 Date: Wed, 04 Aug 2004 23:04:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch] Message-ID: <20040804230242.GA10332@nevyn.them.org> Mail-Followup-To: Jim Blandy , Andrew Cagney , gdb@sources.redhat.com References: <4111145F.7000504@gnu.org> <41112BAE.9080304@gnu.org> <41115B4F.1080700@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00052.txt.bz2 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. 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. > 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. This just means auditing every site that references a memory variable's "address" and making them either fail (conservative) or use some helper which understands a list of pieces. There's a large number, but most of them are trivial. I don't think it will really take very long to do, on the GDB timescale. -- Daniel Jacobowitz