RE: No error for Linker Section Overlapping

["Deepen Mantri" <Deepen.Mantri@kpitcummins.com>]

On Sat, 21st April 2007 at 10:31:18 +0930 Alan Modra wrote:	

> >>  Also the allocation of the LMA address to non-loadable sections

> >>  (such as ".bss" section) is not prevented.		
> Why is this a problem?	 	 

I faced the problem while linking one of my project because of LMA

assignment to .bss section.		

Following is the relevant part from the linker script used in that
project:
////////////////////////////////////////////////////////////////////////
///
.
.
.data 0x3f00: AT(_mdata)  --> _mdata is some Load address from ROM
region
{
  _data = .;
  *(.data) 
  _edata = .; 
}>ram 

.bss 
{
    _bss = . ;
    *(.bss)
    *(COMMON)
     _ebss = . ;
     _end = . ;
} > ram
.
.
////////////////////////////////////////////////////////////////////////
//

The .bss section was assigned the LMA which was the end LMA of .data	
section. So .bss section consumed the space in ROM even though being the

non-loadable section.		
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.		

> Changing this as you have done will break other code in the linker,	
> eg. _bfd_elf_map_sections_to_segments.	

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.	

Using binutils 2.16.92 following segments got generated in which various

sections are mapped respectively. 
////////////////////////////////////////////////////////////////////////
/
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 
   01     .tors 
   02     .data 
   03     .bss 
////////////////////////////////////////////////////////////////////////
//   

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 
   01     .tors 
   02     .data .bss 
////////////////////////////////////////////////////////////////////////
//

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 
   01     .tors 
   02     .data 
   03     .bss 
////////////////////////////////////////////////////////////////////////
//

Isn't this the expected behaviour? 

> Changing this as you have done will break other code in the linker,	

Could you please explain me in detail, what could be the other
consequences
of the modifications done? 
This will help me to investigate the problem further.

Regards,		
Deepen Mantri		

KPIT Cummins InfoSystems Ltd.		
Pune, India		
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~