From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24280 invoked by alias); 2 May 2006 07:48:23 -0000 Received: (qmail 24265 invoked by uid 22791); 2 May 2006 07:48:22 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 May 2006 07:48:20 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k427mHAe030509; Tue, 2 May 2006 03:48:17 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k427m6oR032643; Tue, 2 May 2006 03:48:06 -0400 Received: from [10.32.68.10] (vpn-68-10.surrey.redhat.com [10.32.68.10]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k427m5RC013369; Tue, 2 May 2006 08:48:05 +0100 Message-ID: <44570EB2.3010600@redhat.com> Date: Tue, 02 May 2006 07:48:00 -0000 From: Nick Clifton User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Torsten Mohr CC: binutils , newlib@sourceware.org Subject: Re: linker script for V850? References: <200604282216.40360.tmohr@s.netic.de> <200604290803.52100.tmohr@s.netic.de> <200604291513.k3TFDGLj004389@greed.delorie.com> <200604292043.09647.tmohr@s.netic.de> In-Reply-To: <200604292043.09647.tmohr@s.netic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00025.txt.bz2 Hi Torsten, First of all, this question should be asked on the binutils mailing list (binutils@sourceware.org) since it concerns the linker and linker scripts and not the newlib mailing list since it does not concern the newlib C library. I am adding a CC to the the binutils list and I suggest that future respondents remove the CC to newlib. Second of all, it really helps if you can provide a *small* reproducible example when you encounter a problem like this. It lets us investigate the problem on our own machines, often leading to a much speedier answer. Also you do not mention which version of the linker you are using, nor whether you have checked to see if this problem still exists with the sources in the mainline binutils CVS repository. (It may be that there is an actual bug in the linker that you are using and that this bug has now been fixed). > So i tried to split it into two sections ".tdata_ram" and > ".tdata_rom": > > .tdata_ram ALIGN (4) : > { > PROVIDE (__ep = .); > *(.tbyte) > *(.tcommon_byte) > *(.tbss) > *(.tcommon) > } >ram > > .tdata_rom ALIGN (4) : > { > *(.tdata) > } >ram AT>rom In theory this looks like the right way to solve your problem. > But this also fails. I expected this to work, as i really separate > RAM and ROM. The error at linking is this: > > v850e-unknown-elf-gcc -o hw2.elf \ > Â Â Â Â Â Â Â Â -Wl,-Map=hw2.map \ > Â Â Â Â Â Â Â Â -Wl,-Tv850.x \ > Â Â Â Â Â Â Â Â main.o vectors.o > c:\v850e\bin\..\lib\gcc\v850e-unknown-elf\3.4.6\..\..\..\.. > \v850e-unknown-elf\bin\ld.exe: address 0x75ec of hw2.elf section .tdata is > not within region ram Have you tried separating the .tdata_ram and .tdata_rom sections so that the .tdata_rom section is near the beginning of the SECTIONS part of the linker script, with the other sections that are being placed into the rom memory region and the .tdata_ram section is near the end of the SECTIONS part of the script, with the other sections that are being placed into the ram memory region ? Cheers Nick