From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24742 invoked by alias); 17 Nov 2004 03:42:16 -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 24732 invoked from network); 17 Nov 2004 03:42:11 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 17 Nov 2004 03:42:11 -0000 Received: (qmail 19697 invoked by uid 10); 17 Nov 2004 03:42:11 -0000 Received: (qmail 27955 invoked by uid 500); 17 Nov 2004 03:41:59 -0000 Mail-Followup-To: binutils@sources.redhat.com, drow@false.org From: Ian Lance Taylor To: Daniel Jacobowitz Cc: binutils@sources.redhat.com Subject: Re: RFA: Support for Thumb in dynamic objects References: <20041116233909.GA31434@nevyn.them.org> <20041117030226.GA3884@nevyn.them.org> Date: Wed, 17 Nov 2004 03:42:00 -0000 In-Reply-To: <20041117030226.GA3884@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00248.txt.bz2 Daniel Jacobowitz writes: > > There is, of course, a second related issue, which is whether the > > other objects involved in the dynamic link are compiled with > > interworking support. In my case I could not assume that. So while > > my linker doesn't add a stub for each R_ARM_THM_PC22 reloc--it just > > changes those to blx when appropriate--it does automatically add a > > stub for ABS32 and GOT32 references to Thumb code. I don't have a > > good automatic solution here--perhaps the new new ABI, which I gather > > requires interworking support, will take the issue off the table. > > > > Along similar lines it is quite easy for the linker to generate stubs > > for all functions potentially referenced by non-interworking code, so > > the need for the -mcallee-super-interworking option goes away. > > I haven't done any work on the linker equivalents of super > interworking, since I didn't need them at the time. If you'd like to > contribute it, of course... :-) Of course, before I can contribute them, we have to work out the issues of when you can use ARMv5T and when you can't assume the code supports interworking.... (Of course the linker can only handle -mcallee-super-interworking. -mcaller-super-interworking requires compiler support. That was unfortunately broken since it was written; I implemented my own version, only to discover that it has been fixed in the current compiler anyhow. (Although I do wonder what happens with the current compiler when using a shared libgcc and making a caller-super-interworking call via ip.)) Ian