From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8289 invoked by alias); 25 Jul 2007 18:12:17 -0000 Received: (qmail 8129 invoked by uid 22791); 25 Jul 2007 18:12:16 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jul 2007 18:12:13 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1IDlL1-0008I3-00; Wed, 25 Jul 2007 19:11:55 +0100 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1IDlKv-0002Eu-00; Wed, 25 Jul 2007 19:11:49 +0100 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1IDlKv-0002C9-9p; Wed, 25 Jul 2007 19:11:49 +0100 Date: Wed, 25 Jul 2007 19:43:00 -0000 From: "Maciej W. Rozycki" To: Jim Blandy cc: gdb-patches@sourceware.org, Nigel Stephens , Chris Dearman , "Maciej W. Rozycki" Subject: Re: Use the address mask with addresses for SREC, etc. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00278.txt.bz2 On Wed, 25 Jul 2007, Jim Blandy wrote: > It's my understanding that addresses are signed on MIPS architectures, > and thus 32-bit SREC files are only capable of addressing locations > 0xffffffff80000000 -- 0x000000007fffffff. And that the issue you're > fixing here arises from BFD handing you addresses read from an SREC > file (which is using 32-bit addresses) in the 0x80000000 -- 0xffffffff > range. Is that right? That is correct. The same applies to the HEX formats. I gather this is more or less the reason dump.exp skips testing these formats for pure 64-bit targets (but MIPS is "impure"). Note that the actual MIPS target may be 32-bit making the notion of the signedness of addresses irrelevant, but BFD is still 64-bit causing trouble inbetween. > I'm not too happy with complicating code in GDB because BFD is > providing it with the wrong addresses. I have to imagine the same > thing would happen elsewhere. When BFD reads the SREC file, does it Well, the issue hits here and there across the whole src/ tree every once in a while. It looks like MIPS is about the only oddball to have its addresses signed -- which is actually the result of how the (smart) extension from a 32-bit to a 64-bit CPU has been made (FYI, bits 31 and 63 differentiate between kernel- and user-mode addresses for 32-bit and 64-bit addressing respectively). > have any idea that it's a MIPS SREC file? It looks like > bfd_get_sign_extend_vma doesn't know about MIPS SREC targets; would > fixing that, and then bfd/srec.c, help us get the right addresses into > the BFD? Well, AFAICS SREC and HEX files are target-agnostic, much like "binary" BFD. The only possible way of handling it in BFD itself would be by sign-extending addresses at the "right point" if the destination BFD implies bfd_get_sign_extend_vma() true. I somehow dislike hardcoding the "right point" in {ihex,srec,tekhex}.c, but given these formats appear to me as pure 32-bit, perhaps chosing bit 31 as the "right point" is OK. What do you think? Maciej