From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18189 invoked by alias); 18 Jul 2002 10:11:05 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 18182 invoked from network); 18 Jul 2002 10:11:03 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 18 Jul 2002 10:11:03 -0000 Received: by fw-cam.cambridge.arm.com; id LAA26500; Thu, 18 Jul 2002 11:11:01 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma026194; Thu, 18 Jul 02 11:10:39 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2 [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA28174; Thu, 18 Jul 2002 11:10:39 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA14230; Thu, 18 Jul 2002 11:10:38 +0100 (BST) Message-Id: <200207181010.LAA14230@cam-mail2.cambridge.arm.com> To: Adam Nemet cc: binutils@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [PATCH, arm] Thumb shared library support: Thumb PLT, etc. In-reply-to: Your message of "17 Jul 2002 16:03:17 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jul 2002 04:11:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-07/txt/msg00449.txt.bz2 > Hi, > > This is the second piece of a series of patches to make shared > libraries work on Thumb. The first (yet unreviewed) patch was a GCC > patch: http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00398.html . > > This patch among other things adds a new switch --thumb-plt to > generate Thumb PLT on ARM ELF. My third patch will handle the > interworking aspects of this new flag. > > I ran the GCC testsuite with all combinations of -marm/-mthumb and > /-fPIC. I also did lots of manual testing especially on the lazy > relocation part as our (LynxOS) ld.so does not support that. A > slightly different form of this patch has been part of our ld (2.10.1) > for sometime now and underwent extensive testing. > > Please apply if OK. > Adam Hmm, there's some useful stuff in here, but I don't think it's quite right yet. First of all, do you have a copyright assignment in place for binutils (and gcc, for your other patch)? Until that's sorted out we can't use your code. Now for some comments. 1) I don't like the idea of having some special flag (--thumb-plt) that indicates that we should build a different type of PLT. The linker must be able to figure this out automatically, or we will end up with major problems when it comes to interworking. > > + static const insn16 elf32_thumb_plt0_entry [THUMB_PLT_ENTRY_SIZE / 2] = > + { > + 0xb500, /* push {lr} */ > + 0xb082, /* sub sp, #8 */ > + 0x9000, /* str r0, [sp] */ > + 0x4807, /* ldr r0, [pc, #28] */ > + 0x300c, /* add r0, #12 */ > + 0x4478, /* add r0, pc */ > + 0x4686, /* mov lr, r0 */ > + 0x6800, /* ldr r0, [r0] */ > + 0x9001, /* str r0, [sp, #4] */ > + 0xbd01 /* pop {r0, pc} */ > + }; > + Hmm, would you really want the entry point in your dynamic linker to be Thumb code? The first thing it has to do is stack every register, so i'd have thought a switch to ARM state in the stub would be in order. See also the comments below re sharing with ARM code. > /* Subsequent entries in a procedure linkage table look like > this. */ > ! static const bfd_vma elf32_arm_plt_entry [ARM_PLT_ENTRY_SIZE / 4] = > { > 0xe59fc004, /* ldr ip, [pc, #4] */ > 0xe08fc00c, /* add ip, pc, ip */ > 0xe59cf000, /* ldr pc, [ip] */ > 0x00000000 /* offset to symbol in got */ > }; > + > + /* Note that on ARMv5 and above unlike the ARM PLT entries, the Thumb > + entry can switch mode depending on the corresponding address in the > + GOT. The dynamic linker should set or clear the last bit of the > + address in the GOT accordingly. */ > + > + static const insn16 elf32_thumb_plt_entry [THUMB_PLT_ENTRY_SIZE / 2] = > + { > + 0xb082, /* sub sp, #8 */ > + 0x9000, /* str r0, [sp] */ > + 0x4802, /* ldr r0, [pc, #8] */ > + 0x4478, /* add r0, pc */ > + 0x4684, /* mov ip, r0 */ > + 0x6800, /* ldr r0, [r0] */ > + 0x9001, /* str r0, [sp, #4] */ > + 0xbd01, /* pop {r0, pc} */ > + 0x0000, /* offset to symbol in got */ > + 0x0000 > + }; > We need more space for the thumb sequence than we do for an ARM one. That suggests that we should probably be looking to switch to ARM code for the stub. For example, we could use .code 16 .align 2 _plt_stub_thumb: bx pc nop .code 32 _plt_stub_arm: ldr ip, [pc, #8] add ip, pc, ip ldr ip, [ip] bx ip .word offset_to_target which means we can share the stub with both ARM and Thumb code. So while this is now 6 words long we save on duplication, and we have interworking from the start. Further, if we know we are targeting v5 we can adjust the caller to use blx so that it jumps straight to the ARM entry point, and since loading the pc from memory will cause an arm<->thumb transition if required then we can revert to the more efficient sequence that is the default ARM case. I think most of the rest of the changes are just a natural consequence of how we design the PLT stubs, so I'm not going to concentrate on that until we have the above sorted out. R.