From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22291 invoked by alias); 17 Nov 2004 03:02:37 -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 22242 invoked from network); 17 Nov 2004 03:02:31 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 17 Nov 2004 03:02:31 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CUG5S-00011Z-R3 for ; Tue, 16 Nov 2004 22:02:26 -0500 Date: Wed, 17 Nov 2004 03:02:00 -0000 From: Daniel Jacobowitz To: binutils@sources.redhat.com Subject: Re: RFA: Support for Thumb in dynamic objects Message-ID: <20041117030226.GA3884@nevyn.them.org> Mail-Followup-To: binutils@sources.redhat.com References: <20041116233909.GA31434@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00246.txt.bz2 On Tue, Nov 16, 2004 at 08:37:31PM -0500, Ian Lance Taylor wrote: > My main comment is that I've done similar work, but I had the luxury > of simply assuming ARMv5t. You can do so much better in that case > that I do think we need to let the linker make that assumption when > possible. The easy way to do it automatically would be to say that if > any input .o file is marked for a processor supporting ARMv5t or > above, we can assume that the output will be too, and we can use > ARMv5t in the PLT support, etc. That's what I've done in the past - a previous version of this patch used this to select v4t interworking capable PLT entries. But - none of that is EABI compliant. I don't know whether the EABI has got anything to say on this subject yet; I know it was discussed. But the way the GNU tools use ELF header flags is noncompliant, so I've been trying not to introduce more uses. So I just punted on the issue. > 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... :-) -- Daniel Jacobowitz