From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4979 invoked by alias); 10 Sep 2002 15:49:59 -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 4938 invoked from network); 10 Sep 2002 15:49:56 -0000 Received: from unknown (HELO mailhost.intrinsity.com) (208.246.32.130) by sources.redhat.com with SMTP; 10 Sep 2002 15:49:56 -0000 Received: from victoria.eng.evsx.com (victoria.eng.evsx.com [192.168.1.29]) by mailhost.intrinsity.com (Postfix) with ESMTP id B9F453F3D2; Tue, 10 Sep 2002 10:49:55 -0500 (CDT) Received: from beeville.vert.intrinsity.com (beeville.vert.intrinsity.com [192.168.3.48]) by victoria.eng.evsx.com (8.10.1/8.10.1) with ESMTP id g8AFnt029438; Tue, 10 Sep 2002 10:49:55 -0500 (CDT) From: Fred Fish Received: (from fnf@localhost) by beeville.vert.intrinsity.com (8.11.2/8.11.4) id g8AFnIb24401; Tue, 10 Sep 2002 10:49:18 -0500 Message-Id: <200209101549.g8AFnIb24401@beeville.vert.intrinsity.com> Subject: MIPS sign extension of addresses To: binutils@sources.redhat.com Date: Tue, 10 Sep 2002 08:49:00 -0000 Cc: gdb@sources.redhat.com, fnf@intrinsity.com Reply-To: fnf@intrinsity.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00078.txt.bz2 I'm currently working on a mipsisa32-elf based toolchain and was concerned about the number of failures in the gdb testsuite. For example, using the latest development versions of gcc, gdb, binutils, and newlib (latest as of a week ago anyway), the standard mipsisa32-elf configured toolchain gets the following results just for "mips-sim-idt32/-msoft-float", excluding the gdb.mi, gdb.gdbtk, and gdb.threads tests: # of expected passes 5689 # of unexpected failures 281 # of expected failures 29 # of unresolved testcases 41 # of untested testcases 3 # of unsupported tests 15 After doing some work on gdb and the testsuite over the weekend, my results for the mips-elf toolchain are: # of expected passes 6126 # of unexpected failures 91 # of expected failures 39 # of unresolved testcases 28 # of untested testcases 3 # of unsupported tests 6 # of unexpected successes 1 Most of the problems I fixed had to do with the fact that BFD takes the 32 bit unsigned addresses from object and executable files, sign extends them, and then stores the result as a bfd_vma, which is an unsigned 64 bit type (unsigned long long). For example, the unsigned 32 bit address 0x80020004 becomes an unsigned 64 bit bfd_vma/CORE_ADDR of 0xffffffff80020004. The bfd_vma type is used to define gdb's CORE_ADDR types. I suppose this might make more sense to me if I either had more historical knowledge about why it does this, or if bfd_vma/CORE_ADDR were signed types. The trigger for this behavior in BFD is the field called sign_extend_vma in the elf backend data, which apparently is only set by elf32-mips.c, elf32-sh64.c, and elfn32-mips.c. This special treatment for mips seems to also be why we need the regcache to support a read_signed_register call that is only used in mips-tdep.c. There are also some ADDR_BITS_REMOVE macros used in mips-tdep.c that one might think would be there to strip the high bits but really don't since that macro invokes mips_mask_address_p() which tests mask_address_var which defaults to AUTO_BOOLEAN_AUTO which uses MIPS_DEFAULT_MASK_ADDRESS_P which checks the multiarch value of default_mask_address_p which seems to be set to zero everywhere. Is all of this just internal gdb handwaving that can be changed/fixed or are there external reasons for all this sign extending followed by selective discarding/ignoring of the extended bits? Are there files that will break or hardware that will misbehave if BFD stops doing this sign extension? After getting a little feedback from some private email exchanges containing substantially the same info as above, I've modified my mental picture of this process to think of it as a simple address translation scheme. I.E. when running a 32 bit binary in a 64 bit address space, effectively the 32 bit address space is split in half, with the lower half (0x00000000-0x7FFFFFFF) mapped to the bottom of the 64 bit space and the upper half (0x80000000-0xFFFFFFFF) mapped to the top of the 64 bit space. I suppose this makes sense in a toolchain where you want the same gdb to be able to handle both 64 and 32 bit mips. I'm fairly unfamiliar with all the different possible mips configurations, but perhaps it would be less confusing if there was one that was strictly 32 bit internally, much like when configuring and building a native i686-pc-linux-gnu toolchain uses an "unsigned long int" type for bfd_vma instead of an "unsigned long long int". -Fred