From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1952 invoked by alias); 24 Feb 2014 15:07:39 -0000 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 Received: (qmail 1942 invoked by uid 89); 24 Feb 2014 15:07:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout1.w1.samsung.com Received: from mailout1.w1.samsung.com (HELO mailout1.w1.samsung.com) (210.118.77.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Mon, 24 Feb 2014 15:07:37 +0000 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N1I00ATUA0MAOA0@mailout1.w1.samsung.com> for binutils@sourceware.org; Mon, 24 Feb 2014 15:07:34 +0000 (GMT) Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id A6.40.18565.4306B035; Mon, 24 Feb 2014 15:07:32 +0000 (GMT) Received: from [106.109.8.100] by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0N1I004NDA0KT850@eusync3.samsung.com>; Mon, 24 Feb 2014 15:07:32 +0000 (GMT) Message-id: <530B6043.4070605@samsung.com> Date: Mon, 24 Feb 2014 15:07:00 -0000 From: Yury Gribov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-version: 1.0 To: nick clifton , Will Newton Cc: "binutils@sourceware.org" , Viacheslav Garbuzov , Yuri Gribov Subject: Re: [RFC][PATCH] Handle arbitrary .plt/.got displacements in ld on ARM References: <52F4B2B3.8060804@samsung.com> <52F8BD92.5080609@samsung.com> <5307609F.8070001@redhat.com> In-reply-to: <5307609F.8070001@redhat.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00135.txt.bz2 Nick Clifton wrote: > I wonder however whether it would be possible to remove the new command > line option and have the linker automatically decide between using > 28-bit or 32-bit PLT entries ? The problem is that decision on PLT entry size is done long before we actually output PLT entries. Fixing this would require a non-trivial code churn which I'm a bit scared to do... Note that most of the people are probably ok with existing 28-bit entries (otherwise we'd know about this issue long ago). -Y