From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26236 invoked by alias); 24 Feb 2005 10:39:27 -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 25931 invoked from network); 24 Feb 2005 10:39:10 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 24 Feb 2005 10:39:10 -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 j1OAd74m007714; Thu, 24 Feb 2005 10:39:07 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 j1OAd8rg019811; Thu, 24 Feb 2005 10:39:08 GMT Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id j1OAd6fu019807; Thu, 24 Feb 2005 10:39:06 GMT X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: arm-elf-ld: problems with long calls in thumb mode From: Richard Earnshaw To: Lars Olsson Cc: binutils@sourceware.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1109241545.2361.12.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Thu, 24 Feb 2005 16:16:00 -0000 X-SW-Source: 2005-02/txt/msg00585.txt.bz2 On Thu, 2005-02-24 at 10:08, Lars Olsson wrote: > Hi, > > I'm working on a platform with an arm7tdmi chip with a large (but slow) > flashrom and a small, fast sram. Code is in thumb mode. The flashrom is used to > store collected data as well as providing non-volatile storage for the program > code. On bootstrap, all code is copied from flash to ram because speed is of > essence. This works as intended. > > However, I'm getting to the point where I'm running out of ram and I would like > to skip copying non-critical functions to ram in order to save some space and > here I experience problems with the linker: > > thumb/send.o(.text+0x10): In function `InitRS232': > send.c:39: relocation truncated to fit: R_ARM_THM_PC22 _call_via_r3 > thumb/send.o(.text+0x20):send.c:40: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r3 > thumb/send.o(.text+0x58): In function `SendData': > send.c:71: relocation truncated to fit: R_ARM_THM_PC22 _call_via_r4 > thumb/send.o(.text+0x60):send.c:72: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r4 > thumb/send.o(.text+0x6a):send.c:76: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r3 > thumb/send.o(.text+0x7a):send.c:79: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r4 > thumb/send.o(.text+0x8c):send.c:82: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r3 > thumb/send.o(.text+0xa0):send.c:83: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r4 > thumb/send.o(.text+0xa6):send.c:85: relocation truncated to fit: R_ARM_THM_PC22 > _call_via_r3 > thumb/send.o(.text+0xda):send.c:103: relocation truncated to fit: > R_ARM_THM_PC22 _call_via_r3 > thumb/send.o(.text+0xea):send.c:106: additional relocation overflows omitted > from the output > > I have looked for information regarding this behaviour and I've seen > that other people have also run into similar situations, but I haven't > found a solution. The problem seems to be that the 'bl' instruction can't > bridge the gap between flash and ram so the linker tries to use the > _call_via_rX routines as intermediates. However, these routines are in libgcc > which are linked only to the ram address which means they too are unreachable > from flash! Is there anyway to get the linker to smarten up and place these > routines in flash as well as in ram so that functions can be called from either > place? > > > Thanks, > /Lars This is gcc PR target/7525. It's been fixed for gcc-4 for other reasons, but it's not going to get back-ported onto any older compilers since it doesn't fix a regression. You can try using the trunk compiler, or you could try and back-port the change yourself if you wished, but it might require some adjustment to work with the older code. R.