From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23263 invoked by alias); 17 Nov 2004 13:48:48 -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 23176 invoked from network); 17 Nov 2004 13:48:29 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 17 Nov 2004 13:48:29 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id iAHDlPso012039; Wed, 17 Nov 2004 13:47:25 GMT Received: from pc960.cambridge.arm.com (localhost.localdomain [127.0.0.1]) by pc960.cambridge.arm.com (8.12.8/8.12.8) with ESMTP id iAHDm7gK022291; Wed, 17 Nov 2004 13:48:07 GMT Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id iAHDm7tH022289; Wed, 17 Nov 2004 13:48:07 GMT X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: RFA: Support for Thumb in dynamic objects From: Richard Earnshaw To: Daniel Jacobowitz Cc: binutils@sources.redhat.com In-Reply-To: <20041116233909.GA31434@nevyn.them.org> References: <20041116233909.GA31434@nevyn.them.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1100699286.22014.14.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Wed, 17 Nov 2004 13:48:00 -0000 X-SW-Source: 2004-11/txt/msg00251.txt.bz2 On Tue, 2004-11-16 at 23:39, Daniel Jacobowitz wrote: > 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. This is also essential for BE-8 support. Without it we can't byte-swap correctly (though if byte-swapping were to be integrated into the linker it could be fudged some other way). > - 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. Not withstanding the need to invent some suitable way of describing the input object files, ld needs to start handling the -mcpu and -march flags that we currently pass to the compiler and the linker. There are times when building objects that can run on multiple ARM machines where we can't safely determine that because one object file uses (for example) v5t, that it is safe to use v5t instructions everywhere. > > OK? Comments? This is OK once you've addressed the point Paul raised. You might also have to look at the tests when run in big-endian mode too. R.