From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2715 invoked by alias); 30 Jan 2004 15:06:35 -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 2682 invoked from network); 30 Jan 2004 15:06:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Jan 2004 15:06:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AmaE6-00085j-3p for ; Fri, 30 Jan 2004 10:06:34 -0500 Date: Fri, 30 Jan 2004 15:06:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: DW_OP_piece coming in gcc 3.4 Message-ID: <20040130150633.GA30879@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20040130052757.301704B104@berman.michael-chastain.com> <20040129225153.19a9fce5@saguaro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040129225153.19a9fce5@saguaro> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00342.txt.bz2 On Thu, Jan 29, 2004 at 10:51:53PM -0700, Kevin Buettner wrote: > On Fri, 30 Jan 2004 00:27:57 -0500 (EST) > mec.gnu@mindspring.com (Michael Elizabeth Chastain) wrote: > > > I'm getting this with gcc-3_4-branch -gdwarf-2: > > > > (gdb) PASS: gdb.base/store.exp: up print old l - longest > > print r^M > > Unhandled dwarf expression opcode 0x93^M > > (gdb) FAIL: gdb.base/store.exp: up print old r - longest > > > > We need a strategic decision: > > > > (1) Implement DW_OP_piece in time for gdb 6.1. > > (2) Ask gcc to not emit DW_OP_piece in gcc 3.4. > > (3) File a PR (or tag onto PR gdb/1312 but that's not really right), > > KFAIL the tests, add a note to PROBLEMS. > > > > I don't know which strategy is good for gdb. > > > > What will it be? > > The "right" thing is to get DW_OP_piece support into gdb (#1). I'm > firmly against #2. #3 may be an acceptable as a short term solution, > but I'm none too fond of it either. > > So, I vote for #1. I agree. I think that adding it to LOC_COMPUTED, especially in an initial form that does not allow changing piecewise values (not_lval) will be pretty simple. Adding it as a first-class citizen all over GDB is a little trickier, since it means checking every use of SYMBOL_VALUE_ADDRESS on non-minsyms. One cleanup I've been meaning to do for ages, but not had time, is to break SYMBOL_VALUE_ADDRESS into three macros. One for minimal symbols, one for partial symbols, and one for full symbols. That would let us get a much better feel for the scope of the problem. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer