From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27265 invoked by alias); 8 Jan 2013 19:15:59 -0000 Received: (qmail 27254 invoked by uid 22791); 8 Jan 2013 19:15:57 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jan 2013 19:15:53 +0000 Received: by mail-wi0-f173.google.com with SMTP id hn17so31816wib.0 for ; Tue, 08 Jan 2013 11:15:52 -0800 (PST) X-Received: by 10.194.242.69 with SMTP id wo5mr103653089wjc.10.1357672552124; Tue, 08 Jan 2013 11:15:52 -0800 (PST) Received: from localhost ([2.26.203.77]) by mx.google.com with ESMTPS id ex6sm420763wid.3.2013.01.08.11.15.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Jan 2013 11:15:50 -0800 (PST) From: Richard Sandiford To: Robert Schiele Mail-Followup-To: Robert Schiele ,binutils@sourceware.org, rdsandiford@googlemail.com Cc: binutils@sourceware.org Subject: Re: invocation of mips_elf_multi_got can cause not enough GOT space for local GOT entries References: Date: Tue, 08 Jan 2013 19:15:00 -0000 In-Reply-To: (Robert Schiele's message of "Tue, 8 Jan 2013 15:31:32 +0100") Message-ID: <87a9sj32qj.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00104.txt.bz2 Robert Schiele writes: > On Tue, Jan 8, 2013 at 12:10 PM, Robert Schiele wrote: >> Thus I wonder whether it is actually unexpected behavior that this >> relative changes occur or if this is expected behavior it seems quite >> obvious to me that the assumption of mips_elf_multi_got it makes about >> calculation of the new page numbers cannot be generally correct. > > I also did some bisecting to see when the problem first occurred. In > fact I saw it first after > http://sourceware.org/ml/binutils/2008-06/msg00273.html got committed. > Obviously this does not mean that this is the culprit since the bug > could just have been triggered by that in my case. But it could also > be that this change invalidates some assumptions that were made in the > original implementation as described in my previous mails. > > Richard, since it seems the original implementation of this idea > (http://sourceware.org/ml/binutils/2007-10/msg00409.html) and the > patch that seems to break it > (http://sourceware.org/ml/binutils/2008-06/msg00273.html) are from > you, you might have the best idea of what might be going wrong here. Sorry, it's going to very hard to help here without a testcase. Can you give any more information about the relocations whose offsets changed? Richard