From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12390 invoked by alias); 17 Nov 2004 01:37:45 -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 12359 invoked from network); 17 Nov 2004 01:37:40 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 17 Nov 2004 01:37:40 -0000 Received: (qmail 28626 invoked by uid 10); 17 Nov 2004 01:37:40 -0000 Received: (qmail 4215 invoked by uid 500); 17 Nov 2004 01:37:31 -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> Date: Wed, 17 Nov 2004 01:37:00 -0000 In-Reply-To: <20041116233909.GA31434@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/msg00243.txt.bz2 Daniel Jacobowitz writes: > This patch adds limited support for Thumb in dynamic objects. It causes the > glue stubs not to be exported from the object, and uses a prefix to the PLT > entry to change mode instead of a glue stub off somewhere else. It also > fixes objdump to display thumb functions using the STT_ARM_TFUNC type as > functions. > > It's easy to stop using STT_ARM_TFUNC and start using an odd symbol value > for dynamic objects; but I didn't want to mix it with this patch. So that's > a TODO. Other TODOs are: > - some kind of mappng symbols in the .plt section so that the disassembler > knows what to do (we can't easily generate new local symbols from the > backend, but I'm sure there's a way around it); this is very important > for GDB. > - Related, synthetic named symbols for the .plt as implemented for other > architectures. > - BLX support. The only reason I didn't do this is that there's no easy > way to tell if using BLX is OK; i.e. whether we can assume the presence > of ARM v5t. > > OK? Comments? 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. 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. Ian