From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15612 invoked by alias); 31 Jan 2003 21:29:58 -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 15605 invoked from network); 31 Jan 2003 21:29:57 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 31 Jan 2003 21:29:57 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18ekcU-0005O7-00; Fri, 31 Jan 2003 17:30:50 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18eik6-0000ix-00; Fri, 31 Jan 2003 16:30:34 -0500 Date: Fri, 31 Jan 2003 21:29:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Cc: Jim Blandy , Kevin Buettner Subject: DWARF-2 and address sizes Message-ID: <20030131213034.GA2545@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com, Jim Blandy , Kevin Buettner Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00537.txt.bz2 [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? Do we have to worry about a binary in which different compilation units (or different shared objects, even) have a different value for this? 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.) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer