From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10587 invoked by alias); 1 Feb 2003 17:01:26 -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 10580 invoked from network); 1 Feb 2003 17:01:26 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 1 Feb 2003 17:01:26 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18f2ty-0006un-00; Sat, 01 Feb 2003 13:02:06 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18f11c-0007in-00; Sat, 01 Feb 2003 12:01:52 -0500 Date: Sat, 01 Feb 2003 17:01:00 -0000 From: Daniel Jacobowitz To: Daniel Berlin Cc: Andrew Cagney , gdb@sources.redhat.com, Jim Blandy , Kevin Buettner Subject: Re: DWARF-2 and address sizes Message-ID: <20030201170152.GA29662@nevyn.them.org> Mail-Followup-To: Daniel Berlin , Andrew Cagney , gdb@sources.redhat.com, Jim Blandy , Kevin Buettner References: <20030131223639.GA3585@nevyn.them.org> <3B43101B-35AD-11D7-AA6D-000393575BCC@dberlin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B43101B-35AD-11D7-AA6D-000393575BCC@dberlin.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00011.txt.bz2 On Sat, Feb 01, 2003 at 01:20:17AM -0500, Daniel Berlin wrote: > > On Friday, January 31, 2003, at 05:36 PM, Daniel Jacobowitz wrote: > > >On Fri, Jan 31, 2003 at 04:59:56PM -0500, Andrew Cagney wrote: > >>>[Kevin, I noticed you doing some work in this area re S/390, maybe > >>>you've > >>>got a comment? Anyone else? I'm grasping at straws.] > >>> > >>>I'm trying to figure out how to handle addresses in the DWARF > >>>expression > >>>evaluator. First consider DW_OP_deref: the following data is "the > >>>size of > >>>an address on the target machine", which I would personally take to > >>>mean > >>>cu_header->addr_size. Is this ever different from > >>>TARGET_ADDRESS_BIT / > >>>TARGET_CHAR_BIT, which is what Daniel was originally using? > >> > >>I can imagine architectures wack-o enough for cu_header->addr_size != > >>TARGET_ADDRESS_BIT / TARGET_CHAR_BIT. Someone doing a 16 bit port > >>using > >>32 bit elf. > ... > > >I'm willing to document this as an assertion, store the dwarf2 address > >size and signedness somewhere global, and bail if I detect a violation. > >But I'll skip that for now; it can be a later cleanup. I've already > >got too many pieces in this patch. > > > > IIRC, I did it some *other* way, and Jim told me to do it with the way > there now. > Or is that the other way around (He told me to do it some other way, > rather than what's there now, and i never got to it). > I believe I used to use one of the length of one of builtin types, and > he told me to use TARGET_ADDRESS_BIT / TARGET_CHAR_BIT. > The archives should say. Hmm, I didn't see it in the archives, so maybe I need to look further back. I'll check again. Jim, I don't suppose you remember? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer