From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16726 invoked by alias); 31 Jan 2003 22:36:09 -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 16718 invoked from network); 31 Jan 2003 22:36:08 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 31 Jan 2003 22:36:08 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18eleU-0005VX-00; Fri, 31 Jan 2003 18:36:58 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18ejm3-0000ya-00; Fri, 31 Jan 2003 17:36:39 -0500 Date: Fri, 31 Jan 2003 22:36:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com, Jim Blandy , Kevin Buettner Subject: Re: DWARF-2 and address sizes Message-ID: <20030131223639.GA3585@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com, Jim Blandy , Kevin Buettner References: <20030131213034.GA2545@nevyn.them.org> <3E3AF1DC.3040706@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E3AF1DC.3040706@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00541.txt.bz2 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 wonder if MIPS64 Linux kernels do this, since they're technically ELF32? Hmm, probably not. GCC defines the address size as a constant (4) on ip2k and stormy16, and in terms of pointer size elsewhere. I don't know any platform where objects with different pointer sizes can be linked together, and it seems dubiously useful at best. 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. > But I don't think you'll encounter a case where cu_header->addr_size > isn't locally consistent with the rest of the file. > > > Do we have to > >worry about a binary in which different compilation units (or different > >shared objects, even) have a different value for this? > > See if binutils allows it. If not ... Binutils, sadly, doesn't care. It only uses the address size within a compilation unit. > > >If the consensus is "no, that's too stupid to be allowed to live", then > >this > >gets much easier. > > > >(Then consider DW_OP_deref_size; this is a fun one, since it has to be > >zero-extended to the size of an address on the target machine according to > >the spec, and then in GDB it may have to be zero or sign extended to the > >size of a CORE_ADDR for storage. I haven't tested any of this on MIPS yet > >and I don't want to, damn it. I don't know of any MIPS ABI with multiple > >pointer sizes, and you can't link different ABIs, so encountering > >DW_OP_deref_size is probably impossible. I hope.) > > Have a look at dwarf2read.c:read_address() the existing code already > handles one case of this. Yes. I don't know if it sign extends properly in all cases - I guess it does if signed_address_p always matches whether a CORE_ADDR is a signed type, but that's dubious. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer