From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69932 invoked by alias); 22 Feb 2017 12:08:05 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 68994 invoked by uid 89); 22 Feb 2017 12:08:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=distance, Expert X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Feb 2017 12:08:02 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE88161D17; Wed, 22 Feb 2017 12:08:02 +0000 (UTC) Received: from [10.36.117.33] (ovpn-117-33.ams2.redhat.com [10.36.117.33]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1MC801s009448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2017 07:08:01 -0500 Subject: Re: My problem with the LD linker To: Marian Kechlibar , binutils@sourceware.org References: From: Nick Clifton Message-ID: Date: Wed, 22 Feb 2017 12:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00248.txt.bz2 Hi Marian, > I can compile and link them either using: > > * ARMCC/ARMLINK 2.2 > or > * GCC(E) 4.6.3 and Binutils 2.21 or 2.27. > The second option (GCC/Binutils) works for the first four projects, but > the link phase (using ld) fails for the fifth project, saying: > > ======================================================================== > arm-none-symbianelf-ld: > \S60\devices\S60_3rd_FP2_SDK_v1.1\epoc32\release\ARMV5\urel\EEXE.LIB(uc_exe_.o)(.text+0x2): > unresolvable R_ARM_THM_CALL relocation against symbol > `_ZN4User9InvariantEv@@euser{000a0000}[100039e5].dll' > I have a suspicion that the problem is in *size* of the resulting > binary. The "Expert" project is rather big, several times bigger > than the "Cleaner" project. But I do not understand ELF well enough > to remedy the problem. > Is it possible that some section of the resulting ELF file overflows? Yes. It may well be that the executable is so big that the distance from where the Invariant function is being called and where it is being defined will not fit into the Thumb function call instruction. Several ideas come to mind: * Compile for ARM rather than THUMB - the ARM supports a larger address space. * Compile with GCC but link with ARMLINK. (You did say that using ARMCC/ARMLINK works). * Compile with -ffunction-sections and -fdata-sections enabled and then link with -gc-sections enabled. This might help to reduce the code size by eliminating unused code/data. * Change the order of the object files on the linker command line so that uc_exe.o object is located closer to the system library that defines it. * Compile with -mlong-calls enabled so that function calls to far away destinations should work. Cheers Nick