From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10629 invoked by alias); 7 Jun 2006 20:45:20 -0000 Received: (qmail 10621 invoked by uid 22791); 7 Jun 2006 20:45:20 -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, 07 Jun 2006 20:45:15 +0000 Received: from lagash (unknown [194.74.144.146]) by bender.bawue.de (Postfix) with ESMTP id 9B4994534D; Wed, 7 Jun 2006 22:43:44 +0200 (MEST) Received: from ths by lagash with local (Exim 4.62) (envelope-from ) id 1Fo4ra-0007P2-SE; Wed, 07 Jun 2006 21:42:50 +0100 Date: Wed, 07 Jun 2006 23:22:00 -0000 From: Thiemo Seufer To: David Daney , binutils@sourceware.org Subject: Re: RFH/RFC: symbol index overflow in MIPS linker stubs... Message-ID: <20060607204250.GF9732@networkno.de> References: <44871E31.1080909@avtrex.com> <20060607192759.GD9732@networkno.de> <20060607194249.GA18286@nevyn.them.org> <20060607200330.GE9732@networkno.de> <20060607200930.GA19246@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607200930.GA19246@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-06/txt/msg00094.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Jun 07, 2006 at 09:03:30PM +0100, Thiemo Seufer wrote: > > Daniel Jacobowitz wrote: > > > On Wed, Jun 07, 2006 at 08:27:59PM +0100, Thiemo Seufer wrote: > > > > I would favour a two instruction sequence, applications will continue to > > > > grow. There might be some compatibility traps, but at a superficial > > > > glance I haven't found an obvious blocker. > > > > > > If we can change the stub sequence without ABI problems, why waste an > > > instruction? Support both. > > > > Will the stub section support varying entry sizes? I'm not sure. > > This is solveable, as a simple matter of programming, or ignorable, > by padding the shorter entries with a trailing nop. The first two entries are handled specially, this makes the second option more likely. OTOH, saving an instruction when we have anyway branches and memory access in between is probably not worth much. Thiemo