From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21366 invoked by alias); 18 Apr 2006 15:14:28 -0000 Received: (qmail 21358 invoked by uid 22791); 18 Apr 2006 15:14:27 -0000 X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Apr 2006 15:14:25 +0000 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id k3IFDquc007227; Tue, 18 Apr 2006 16:13:52 +0100 (BST) Received: from pc960.cambridge.arm.com ([10.1.255.211]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Apr 2006 16:13:52 +0100 Subject: Re: plt for arm gnu thumb From: Richard Earnshaw To: johnmc@sidsa.es Cc: binutils@sources.redhat.com In-Reply-To: <4385.195.53.86.158.1145361498.squirrel@webmail> References: <4385.195.53.86.158.1145361498.squirrel@webmail> Content-Type: text/plain Message-Id: <1145373227.14054.16.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 Apr 2006 15:45:00 -0000 Content-Transfer-Encoding: 7bit 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-04/txt/msg00231.txt.bz2 On Tue, 2006-04-18 at 12:58, johnmc@sidsa.es wrote: > hello > > > I have just finished a shared library system using the gnu tools for a > system using arm thumb code but I have found that there is a problem in > that the plt is produced for arm code and it does not work correctly . > question - can I force the gnu tools to produce thumb code plt. > > I am using > arm-elf-gcc (GCC) 4.0.1 > GNU ld version 2.16.1 There's only ever going to be a problem if you try to run on an Architecture v4T device. These chips cannot transition to Thumb mode when loading a PC value from memory, but need instead to use a BX instruction. The problem is that for a shared library trampoline we need to: - preserve all of r0-r11, r13 and r14 - have the 'index' of the called function in ip There's simply no way to achieve all that efficiently and support proper interworking on these devices. (v5 and later chips can swap from ARM to Thumb on a load into the PC, so there is no problem there). We investigated this quite thoroughly as part of the EABI development. We concluded that given that the standard trampoline would work on all v4 and earlier chips and all v5 or later chips (ie everything but v4T), and that on v4T the sequence works if the target of the call is entered in ARM state, the best solution overall was to mandate that on a v4T device, the called address must be an ARM instruction (it can transition to Thumb state immediately thereafter). In theory this could all be handled by the linker when constructing the library, but currently the GNU linker does not do this. R.