From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6628 invoked by alias); 20 Jul 2002 18:33: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 16337 invoked from network); 20 Jul 2002 07:26:23 -0000 Received: from unknown (HELO smtp.lynuxworks.com) (207.21.185.24) by sources.redhat.com with SMTP; 20 Jul 2002 07:26:23 -0000 Received: from anemet1.lynx.com (cerebrus.Lynuxworks.COM [207.21.185.19]) by smtp.lynuxworks.com (8.11.2/8.9.3) with ESMTP id g6K7QN725727 for ; Sat, 20 Jul 2002 00:26:23 -0700 Received: (from anemet@localhost) by anemet1.lynx.com (8.9.3/8.8.7) id AAA18394; Sat, 20 Jul 2002 00:32:43 -0700 X-Authentication-Warning: anemet1.lynx.com: anemet set sender to anemet@lnxw.com using -f To: Richard.Earnshaw@arm.com Cc: binutils@sources.redhat.com Subject: Re: [PATCH, arm] Thumb shared library support: Thumb PLT, etc. References: <200207191450.PAA23400@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=US-ASCII From: Adam Nemet Date: Sat, 20 Jul 2002 11:36:00 -0000 In-Reply-To: <200207191450.PAA23400@cam-mail2.cambridge.arm.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2002-07/txt/msg00526.txt.bz2 > All it requires is for the linker to track a bit more information > when pushing an internal PLT data structure onto the list of things > to generate. As long as we can make sure that neither pure ARM nor pure Thumb get punished because of this generalization, I am fine with this and I am ready to change my patch to cover interworking as well. BTW, what do you think about the fini/init parts. Are they acceptable? And what about the GCC patch? > Since we know whether that was an ARM or a Thumb type relocation we > can generate the correct PLT entry without the need to have a > command line switch. I think instead of the relocation type, we should rather look at the the type of the function (STT_FUNC or STT_ARM_TFUNC) we are relocating against. I believe the logic is cleaner if we just consider the PLT as an extension of the shared library and as such it should match the type of the function it calls into. (In case of STT_NOTYPE, we should probably assume that the callee matches the caller.) Of course on the caller side between the caller and the PLT entry, we might need to emit stubs for mode switching the usual way. In your solution if we were to match the instruction set of the caller, if the same PLT entry is referred from a Thumb and an ARM function we have no way to decide which type of PLT entry we need to generate whereas if it matches the callee it is always obvious. I would also prefer to have separate plt for the Thumb entries e.g. .plt.thumb or something like that so that disassembling the plt would be as simple as: objdump -d -j.plt a.out objdump -d -j.plt.thumb --disassembler-option=force-thumb a.out Also note that the Thumb and the ARM PLT entries are of different size (5 words and 4 words) so finding the offset to one entry is easier if we keep them separately. I also plan to issue a warning is someone is trying to mix instrunction sets between the caller and the callee without having the interworking flag set in the ELF header. This is a good indicator that the user doesn't want the interwork overhead but just accidently used the wrong version of the library. This is pretty much a natural extension of the existing warning message when one wants to intermix different non-interworking object files. If we agree on these details I will go and try to extend how PLT is handled currently so that it can provide the functionality for mixing the two types of PLT entries. Adam