From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20243 invoked by alias); 21 Aug 2002 12:25:17 -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 20236 invoked from network); 21 Aug 2002 12:25:17 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Aug 2002 12:25:17 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17hUY4-0006hj-00; Wed, 21 Aug 2002 07:25:20 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17hUYf-0005AV-00; Wed, 21 Aug 2002 08:25:57 -0400 Date: Wed, 21 Aug 2002 05:25:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: static cast from base class to derived class Message-ID: <20020821122557.GA19505@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <200208210600.g7L60qD29529@zenia.red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208210600.g7L60qD29529@zenia.red-bean.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00658.txt.bz2 On Wed, Aug 21, 2002 at 01:00:52AM -0500, Jim Blandy wrote: > > Once when my grandfather was a boy, he was riding his bicycle along a > gravel path, and going pretty fast, when he hit a stone, went flying > over the handlebars, and landed on his face. The gravel was ground so > deeply into his face that, even in his forties, he'd still > occasionally encounter, while shaving, bits of rock that had finally > worked their way out to the surface. > > Here's a patch for a bit of 1998 HP Merge gravel that has finally > found its way to the surface. > > I didn't see any regressions with this patch using either STABS or > Dwarf 2. I'll put together a regression test for the original bug > tomorrow. > > 2002-08-20 Jim Blandy > > * valops.c (value_cast): Simplify and correct logic for doing a > static cast from a pointer to a base class to a pointer to a > derived class. > > Index: gdb/valops.c > =================================================================== > RCS file: /cvs/src/src/gdb/valops.c,v > retrieving revision 1.67 > diff -c -r1.67 valops.c > *** gdb/valops.c 19 Aug 2002 23:19:53 -0000 1.67 > --- gdb/valops.c 21 Aug 2002 02:42:21 -0000 > *************** > *** 361,378 **** > value_zero (t1, not_lval), 0, t1, 1); > if (v) > { > ! struct value *v2 = value_ind (arg2); > ! VALUE_ADDRESS (v2) -= VALUE_ADDRESS (v) > ! + VALUE_OFFSET (v); > ! > ! /* JYG: adjust the new pointer value and > ! embedded offset. */ > ! v2->aligner.contents[0] -= VALUE_EMBEDDED_OFFSET (v); > ! VALUE_EMBEDDED_OFFSET (v2) = 0; > ! > ! v2 = value_addr (v2); > ! VALUE_TYPE (v2) = type; > ! return v2; > } > } > } > --- 361,371 ---- > value_zero (t1, not_lval), 0, t1, 1); > if (v) > { > ! CORE_ADDR addr2 = value_as_address (arg2); > ! addr2 -= (VALUE_ADDRESS (v) > ! + VALUE_OFFSET (v) > ! + VALUE_EMBEDDED_OFFSET (v)); > ! return value_from_pointer (type, addr2); > } > } > } I've got a question... what does VALUE_ADDRESS mean in this context? If it means what it normally means (ought to mean?), then taking an address, subtracting an address, and using it as a pointer doesn't make a lot of sense. Answering my own question - it's dereferencing a pointer to a struct at 0. So we'll actually get an address relative to zero, which makes everything work out. This looks good to me. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer