From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7522 invoked by alias); 15 Apr 2005 17:07:23 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 7258 invoked from network); 15 Apr 2005 17:07:15 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Apr 2005 17:07:15 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j3FH7Axs026132; Fri, 15 Apr 2005 13:07:15 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j3FH79O11796; Fri, 15 Apr 2005 13:07:09 -0400 Received: from [192.168.123.100] (vpn26-17.sfbay.redhat.com [172.16.26.17]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j3FH74YE030730; Fri, 15 Apr 2005 13:07:05 -0400 Subject: Re: [patch] adjust libgloss addresses for 64-bit From: Eric Christopher To: "Maciej W. Rozycki" Cc: Thiemo Seufer , newlib@sources.redhat.com, binutils@sources.redhat.com, cgd@broadcom.com In-Reply-To: References: <1113516346.4591.39.camel@localhost.localdomain> <20050414223754.GI32470@hattusa.textio> <1113583817.4591.68.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 15 Apr 2005 17:07:00 -0000 Message-Id: <1113584821.4591.73.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00429.txt.bz2 > > Of course it is zero-extended. Otherwise it would be a different one; > actually in the CKSEG0 space rather than XKUSEG. If you want the former, > what's wrong with 0xffffffff80000000? -- please keep in mind we are > talking about 64-bit addressing. Hrm. Good point. This thread was mostly because of unpredictable errors from the assembler in crt0.S. The "location" that crt0 is trying to load is "K0BASE" which is likely CKSEG0, and yes, I have sign extended the constant used in the patch that started this thread :) (personally I think if we want to load a constant into a register using a macro we should use li, not la). -eric