From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19673 invoked by alias); 27 Jul 2007 20:22:43 -0000 Received: (qmail 19663 invoked by uid 22791); 27 Jul 2007 20:22:42 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jul 2007 20:22:41 +0000 Received: (qmail 23935 invoked from network); 27 Jul 2007 20:22:39 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Jul 2007 20:22:39 -0000 To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org, Nigel Stephens , Chris Dearman , "Maciej W. Rozycki" Subject: Re: Use the address mask with addresses for SREC, etc. References: From: Jim Blandy Date: Fri, 27 Jul 2007 20:41:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Wed, 25 Jul 2007 19:11:49 +0100 (BST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00300.txt.bz2 "Maciej W. Rozycki" writes: > On Wed, 25 Jul 2007, Jim Blandy wrote: >> 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? For srec.c, that seems reasonable to me. The logic there for writing records will always output "negative" addresses as 32-bit values --- it does not assume that s-records with two- or three-byte addresses will be sign-extended from those lengths. I haven't looked at ihex or texhex. The binutils folks will be the ones to approve the BFD changes, so before you dive into this, you might want to explain your situation there and get their general approval. They might even have better ideas. :)