From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17113 invoked by alias); 17 Nov 2004 22:59:33 -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 16846 invoked from network); 17 Nov 2004 22:59:26 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 17 Nov 2004 22:59:26 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CUYll-0005uL-V2; Wed, 17 Nov 2004 17:59:22 -0500 Date: Wed, 17 Nov 2004 23:06:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: METHOD_PTR_*? Message-ID: <20041117225921.GA22472@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <41912F1E.2000606@gnu.org> <20041109221026.GA10905@nevyn.them.org> <4199541C.1070302@gnu.org> <20041116011518.GA31540@nevyn.them.org> <41996420.20607@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41996420.20607@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00185.txt.bz2 On Mon, Nov 15, 2004 at 09:21:20PM -0500, Andrew Cagney wrote: > Daniel Jacobowitz wrote: > >On Mon, Nov 15, 2004 at 08:13:00PM -0500, Andrew Cagney wrote: > > > >>Daniel Jacobowitz wrote: > >> > >>>On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote: > >>> > >>> > >>>>Hello, > >>>> > >>> > >>>>From value.h: > >>> > >>>>/* Pointer to member function. Depends on compiler implementation. */ > >>>> > >>>>#define METHOD_PTR_IS_VIRTUAL(ADDR) ((ADDR) & 0x80000000) > >>>>#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET)) > >>>>#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR)) > >>>> > >>>>It also depends on the underlying architecture - not very 64-bit > >>>>friendly :-/ > >>> > >>> > >>>Yuck! > >> > >>Can it for the moment be moved out of value.h? > > > > > >What would that accomplish? Where would it move to? > > It would remove it from value.h. That doesn't really answer my question... I assume that you want to move it so that value.h only contains some set of "blessed" "struct value" related routines. But this has no home obviously more appropriate than its current home. > cp-abi.h? How about cp-support.h? -- Daniel Jacobowitz