From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14682 invoked by alias); 10 May 2006 15:05:20 -0000 Received: (qmail 14673 invoked by uid 22791); 10 May 2006 15:05:19 -0000 X-Spam-Check-By: sourceware.org Received: from bender.bawue.de (HELO bender.bawue.de) (193.7.176.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 May 2006 15:05:16 +0000 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id DEB0644F55; Wed, 10 May 2006 17:05:11 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1FdqF0-0003B3-O7; Wed, 10 May 2006 16:04:42 +0100 Date: Wed, 10 May 2006 15:24:00 -0000 From: Thiemo Seufer To: Paul Koning , binutils@sourceware.org Subject: Re: [PATCH] Relax MIPS j/jal out-of-range check Message-ID: <20060510150442.GB27394@networkno.de> References: <20060509141637.GB27291@networkno.de> <20060509141949.GA4951@nevyn.them.org> <17504.43687.511263.125714@gargle.gargle.HOWL> <20060509144931.GA5899@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060509144931.GA5899@nevyn.them.org> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00197.txt.bz2 Daniel Jacobowitz wrote: [snip] > > Daniel> Why? Especially bearing in mind that we're in the assembler > > Daniel> here. This doesn't make sense to me. > > > > If you have a routine that's sometimes called from uncached code, and > > the label is a KSEG0 address, you could call it from KSEG1 code simply > > with > > jal label > > and the machine will do the right thing (you end up at the KSEG1 > > address corresponding to "label"). > > How could you get the assembler to do this? Normally you can't tell if > this is going to overflow until you've linked! Linker errors are a > different kettle of fish. > > I think the warning is just bogus, after looking at it. We're warning > for "jal 0x10000000". But we don't know the location of the jal yet, > so we haven't a clue if it's out of range, do we? The patch is correct, but our explanation was misleading: The code checks for absolute addresses, and warns now if it crosses a 256 MB memory area. This allows e.g. to jump between KSEG0 and KSEG1 without hassles. Thiemo