From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28766 invoked by alias); 18 Feb 2010 04:44:27 -0000 Received: (qmail 28757 invoked by uid 22791); 18 Feb 2010 04:44:26 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Feb 2010 04:44:22 +0000 Received: (qmail 23286 invoked from network); 18 Feb 2010 04:44:21 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Feb 2010 04:44:21 -0000 Date: Thu, 18 Feb 2010 04:44:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: CORE_ADDR representation Message-ID: <20100218044416.GA19485@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-02/txt/msg00118.txt.bz2 This comes up again and again, and has at least three times in the past month with Jan's PIE patches. Is it time for us to have opaque arithmetic on target addresses? My latest problem: struct section_addr_info * build_section_addr_info_from_objfile (const struct objfile *objfile) { ... CORE_ADDR mask = CORE_ADDR_MAX; if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT)) mask = ((CORE_ADDR) 1 << addr_bit) - 1; ... sap->other[i].addr = (bfd_get_section_vma (objfile->obfd, sec) + objfile->section_offsets->offsets[i]) & mask; This truncates the high bits. MIPS sign-extends pointers, even internally in CORE_ADDR, and this results in separate debug info files for MIPS executables being relocated off to la-la land. I had to add this awful thing: if (bfd_get_sign_extend_vma (objfile->obfd) && addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT) && (sap->other[i].addr & ((CORE_ADDR) 1 << (addr_bit - 1))) != 0) sap->other[i].addr |= ~mask; Which I'm not really proposing for inclusion, well, unless no one has a better idea; sepdebug.exp on mips-elf currently fails without this. For instance, should we always internally sign-extend CORE_ADDR? Always internally zero-extend? Having it vary by target has been a recurring problem. -- Daniel Jacobowitz CodeSourcery