From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30648 invoked by alias); 23 Apr 2007 14:57:39 -0000 Received: (qmail 30638 invoked by uid 22791); 23 Apr 2007 14:57:38 -0000 X-Spam-Check-By: sourceware.org Received: from sohm.kpitcummins.com (HELO sohm.kpit.com) (203.197.93.231) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Apr 2007 15:57:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: No error for Linker Section Overlapping Date: Mon, 23 Apr 2007 15:08:00 -0000 Message-ID: In-Reply-To: <20070421010118.GL6840@bubble.grove.modra.org> From: "Deepen Mantri" To: "Alan Modra" Cc: 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 X-SW-Source: 2007-04/txt/msg00311.txt.bz2 On Sat, 21st April 2007 at 10:31:18 +0930 Alan Modra wrote:=09 > >> Also the allocation of the LMA address to non-loadable sections > >> (such as ".bss" section) is not prevented.=09=09 > Why is this a problem?=09=20=09=20 I faced the problem while linking one of my project because of LMA assignment to .bss section.=09=09 Following is the relevant part from the linker script used in that project: //////////////////////////////////////////////////////////////////////// /// =2E =2E .data 0x3f00: AT(_mdata) --> _mdata is some Load address from ROM region { _data =3D .; *(.data)=20 _edata =3D .;=20 }>ram=20 .bss=20 { _bss =3D . ; *(.bss) *(COMMON) _ebss =3D . ; _end =3D . ; } > ram =2E =2E //////////////////////////////////////////////////////////////////////// // The .bss section was assigned the LMA which was the end LMA of .data=09 section. So .bss section consumed the space in ROM even though being the non-loadable section.=09=09 While linking the code, due to large size, the .bss section surpassed the end boundary of ROM region (In this case ROM size was 4K bytes). If the .bss section had not been assigned the LMA, this error would not have been generated.=09=09 > Changing this as you have done will break other code in the linker,=09 > eg. _bfd_elf_map_sections_to_segments.=09 I did the regression after applying the patch, and did not find any unexpected failures. I checked the behaviour of "_bfd_elf_map_sections_to_segments" function also. As per my understanding the behavior is same as in case of binutils 2.16.92.=09 Using binutils 2.16.92 following segments got generated in which various sections are mapped respectively.=20 //////////////////////////////////////////////////////////////////////// / Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x00000000 0x00000000 0x001a8 0x001a8 R E 0x1 LOAD 0x00025c 0x000001a8 0x000001a8 0x00010 0x00010 RW 0x1 LOAD 0x00026c 0x00040000 0x000001b8 0x00008 0x00008 RW 0x1 LOAD 0x000274 0x00040008 0x00040008 0x00000 0x00004 RW 0x1 Section to Segment mapping: Segment Sections... 00 .vects .text .rodata=20 01 .tors=20 02 .data=20 03 .bss=20 //////////////////////////////////////////////////////////////////////// //=20=20=20 In binutils 2.17 .bss section got mapped in the segment in which .data is placed. This is because .bss was assigned the LMA following the .data section. //////////////////////////////////////////////////////////////////////// // Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000094 0x00000000 0x00000000 0x001a8 0x001a8 R E 0x1 LOAD 0x00023c 0x000001a8 0x000001a8 0x00010 0x00010 RW 0x1 LOAD 0x00024c 0x00040000 0x000001b8 0x00008 0x0000c RW 0x1 Section to Segment mapping: Segment Sections... 00 .vects .text .rodata=20 01 .tors=20 02 .data .bss=20 //////////////////////////////////////////////////////////////////////// // By not allocating the LMA to .bss, the behaviour as in the case of previous binutils version is achieved. //////////////////////////////////////////////////////////////////////// // Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x00000000 0x00000000 0x001a8 0x001a8 R E 0x1 LOAD 0x00025c 0x000001a8 0x000001a8 0x00010 0x00010 RW 0x1 LOAD 0x00026c 0x00040000 0x000001b8 0x00008 0x00008 RW 0x1 LOAD 0x000274 0x00040008 0x00040008 0x00000 0x00004 RW 0x1 Section to Segment mapping: Segment Sections... 00 .vects .text .rodata=20 01 .tors=20 02 .data=20 03 .bss=20 //////////////////////////////////////////////////////////////////////// // Isn't this the expected behaviour?=20 > Changing this as you have done will break other code in the linker,=09 Could you please explain me in detail, what could be the other consequences of the modifications done?=20 This will help me to investigate the problem further. Regards,=09=09 Deepen Mantri=09=09 KPIT Cummins InfoSystems Ltd.=09=09 Pune, India=09=09 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C and M32C Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on February 6, 2007. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=09