From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26738 invoked by alias); 4 Feb 2003 02:26:28 -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 26700 invoked from network); 4 Feb 2003 02:26:27 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 172.16.49.205 with SMTP; 4 Feb 2003 02:26:27 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h142GE8A027002; Mon, 3 Feb 2003 21:16:15 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h142GCFj026998; Mon, 3 Feb 2003 21:16:12 -0500 To: Daniel Jacobowitz Cc: Daniel Berlin , Andrew Cagney , gdb@sources.redhat.com, Kevin Buettner Subject: Re: DWARF-2 and address sizes References: <20030131223639.GA3585@nevyn.them.org> <3B43101B-35AD-11D7-AA6D-000393575BCC@dberlin.org> <20030201170152.GA29662@nevyn.them.org> From: Jim Blandy Date: Tue, 04 Feb 2003 02:26:00 -0000 In-Reply-To: <20030201170152.GA29662@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00062.txt.bz2 Daniel Jacobowitz writes: > 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? I'm pretty sure that I saw the code simply using the whole CORE_ADDR to do the dereferencing, and that I said it should be changed to use the target's address size, since, in a gdbarch world, CORE_ADDR could be larger than a target address. I don't think I specified whether one should use cu->addr_size or TARGET_ADDRESS_BIT / TARGET_CHAR_BIT; I doubt it occurred to me that they might be different. Given the way cu_header->addr_size is used in the definition of DW_FORM_addr (section 7.5.4, "Attribute Encodings"), I would expect it to match the size of a linker symbol value --- since the point is to provide something that can be relocated. But every ABI provides relocs for smaller values, too, so it could be different. I guess I don't really understand why this is a big deal. The baton for the expression should record the addr_size and signed_addr_p from the compilation unit it came from. Just use that many bits of CORE_ADDR, sign-extended as directed. If this isn't right, we'll find out eventually. We don't have any authority here to work from, so that's the best we can do. Or am I being too sloppy?