From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22323 invoked by alias); 19 Oct 2011 15:06:43 -0000 Received: (qmail 22311 invoked by uid 22791); 19 Oct 2011 15:06:42 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 15:06:24 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 19 Oct 2011 16:06:17 +0100 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Oct 2011 16:06:12 +0100 Message-ID: <4E9EE764.1030506@arm.com> Date: Wed, 19 Oct 2011 17:37:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ben Gamari CC: "gcc@gcc.gnu.org" Subject: Re: [BUG?] GCC 4.5.2 produces deprecated ARM relocation References: <877h47msrc.fsf@gmail.com> <4E987392.3010806@arm.com> <87aa93e87l.fsf@gmail.com> In-Reply-To: <87aa93e87l.fsf@gmail.com> X-MC-Unique: 111101916061706501 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00323.txt.bz2 On 14/10/11 19:31, Ben Gamari wrote: > On Fri, 14 Oct 2011 18:38:26 +0100, Richard Earnshaw w= rote: >> On 14/10/11 17:40, Ben Gamari wrote: >>> I was recently trying to test GCC's behavior in producing various types >>> of ARM relocations. In particular, I was trying to produce an >>> R_ARM_JUMP24 relocation, which requires veneer. It was suggested that >>> the code most likely to produce this relocation would involve some sort >>> of tail recursion. I wrote up a small test[1] involving interworking and >>> tail recursion to see what the produced object might look like. To my >>> surprise, I found that the compiler instead[2] produced the deprecated >>> R_ARM_PLT32 relocation. Considering the deprecated state of this >>> relocation type, should this be considered a bug? Being a linker >>> implementer, I for one would greatly appreciate it if GCC tried to only >>> use non-deprecated relocation types. I apologize if this has already >>> been fixed upstream. >>> >> >> The compiler doesn't produce relocations, but the assembler does. You >> need to make sure your binutils is up-to-date. >> > Fair enough. I suppose that makes more sense. >=20 > $ as -v > GNU assembler version 2.21.0 (arm-linux-gnueabi) using BFD version (GNU B= inutils for Ubuntu) 2.21.0.20110327 >=20 >=20 > Seems that this is the latest stable release. You need to take that up with the binutils folks, they don't generally hang out on this list. R.