No error for Linker Section Overlapping

No error for Linker Section Overlapping

[Deepen Mantri]

Hi,

Following is my observation regarding the modified LMA assignment done
in the 
binutils 2.17:

Now whenever the VMAs of sections overlap, it is assumed that 
these are overlay sections. Different LMAs are assigned to them instead
of 
reporting any section overlapping error as done in previous versions of 
binutils. 

Following are the relevant lines from my linker script.The size of
".data" 
section is 0x334 bytes which is observed from the map file. So VMAs of
".data"
and ".bss" sections are overlapping.

////////////////////////////////////////////////////////////////////////
/////

.data 0x00FFFA10 : AT (_mdata)
	{
		_data = .;
		*(.data)
		*(.data.*)
		_edata = .;
	}
.gcc_exc :
	{
		*(.gcc_exc)
	}
.bss 0x00FFFA20 :
	{
		_bss = .;
		*(.bss)
		*(COMMON)
		_ebss = .;
		_end = .;
	}
////////////////////////////////////////////////////////////////////////
//////

The VMA overlapping error should have been generated.
Instead, ".bss" section which is a nonloadable section, is assigned a
LMA 
under the same assumption that ".data" and ".bss" are overlay sections. 
(LMA of .bss section) = (LMA of .data section) + (size of .data
section).

Following lines from the generated map file exhibits the same.

////////////////////////////////////////////////////////////////////////
/////

.data           0x00fffa10      0x334     load address 0x000007ba
                0x00fffa10                      _data = .
   .                 .                             .
   .                 .                             . 
   .                 .                             .
   
 *(.data.*)     0x00fffd44                  _edata = .

.gcc_exc
 *(.gcc_exc)

.bss            0x00fffa20      0x6        load address 0x00000aee
                0x00fffa20                  _bss = .
  .                 .                             .
  .                 .                             . 
  .                 .                             .
                  
////////////////////////////////////////////////////////////////////////
/////

What is the benefit of assigning distinct LMAs to the non-overlay
sections 
having overlapped VMAs? 

Is there any way to generate an overlapping error for
non-overlay/non-loadable
sections (such as .bss section),if there VMAs get overlapped?


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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: No error for Linker Section Overlapping

[Alan Modra]

On Thu, Apr 12, 2007 at 06:51:26PM +0530, Deepen Mantri wrote:
> What is the benefit of assigning distinct LMAs to the non-overlay
> sections having overlapped VMAs? 

The changes to lma assignment made using overlays considerably
simpler.  In particular, sections following an overlay area now
don't need their LMAs set.

> Is there any way to generate an overlapping error for
> non-overlay/non-loadable
> sections (such as .bss section),if there VMAs get overlapped?

Assign the LMA as well as the VMA.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: No error for Linker Section Overlapping

[Deepen Mantri]

Hi,

Thank you for the reply.	

>> The changes to lma assignment made using overlays considerably 	
>> simpler.  In particular, sections following an overlay area now	
>> don't need their LMAs set.	

Yes, this is correct. However, it now seems to me that keyword 	
"OVERLAY" has become redundant. Even if you do not use or intend 	
to use it, the sections having overlapped VMAs are going to be 	
considered as overlay sections.	
	
Let's consider this case,	
	
Following is the part of my linker script:	

/////////////////////////////////////////////////////////////////	
.
.
.
.data 0x040000 : AT(_mdata)	
{ 
   _data = .;	
   *(.data) 	
   _edata = .; 	
} > ram	

.mydata1 0x040004 :	
{ 
	.
	.
	BYTE(1);
        LONG(1);
        QUAD(1);
        .
        .
} > ram

.mydata 0x040008 :
{ 
	.
	.
	BYTE(1);
        LONG(1);
        QUAD(1);
        .
        .   
} > ram
.
.
.
//////////////////////////////////////////////////////////////////	

Here "_mdata" is some address of ROM region.	

All the above three sections are overlapping. User has miscalculated	
the sizes of the sections (which can happen quite often) and hence	
assigned the wrong VMAs.	 	

Some sort of alert in the form of warning or error is expected.	 	
Instead, different LMAs are assigned to the sections considering

that they might be overlay sections. So no warning/error is 		
generated.		

Following lines from the map file depict the same:		

///////////////////////////////////////////////////////////////////	
.
.
.
.data           0x00040000        0x8 load address 0x00000368
                0x00040000                _data = .
 *(.data)
 .data          0x00040000        0x0 hwinit.o
 .data          0x00040000        0x8 sample.o
                0x00040004                _z
                0x00040000                _p
 .data          0x00040008        0x0 start.o
 .data          0x00040008        0x0 vects.o
                0x00040008                _edata = .

.mydata1        0x00040004        0xd load address 0x00000370
                0x00040004        0x1 BYTE 0x1
                0x00040005        0x4 LONG 0x1
                0x00040009        0x8 QUAD 0x1

.mydata         0x00040008        0xd load address 0x0000037d
                0x00040008        0x1 BYTE 0x1
                0x00040009        0x4 LONG 0x1
                0x0004000d        0x8 QUAD 0x1
 .
 .
 .
/////////////////////////////////////////////////////////////////////	


>> Assign the LMA as well as the VMA.		
Yes, VMA overlapping error can be generated by this.		

But can't we add an additional check, whether the sections having 	
overlapped VMAs are overlay or not, before changing their LMAs?





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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Alan Modra [mailto:amodra@bigpond.net.au] 
Sent: Saturday, April 14, 2007 6:58 AM
To: Deepen Mantri
Cc: binutils@sources.redhat.com
Subject: Re: No error for Linker Section Overlapping

On Thu, Apr 12, 2007 at 06:51:26PM +0530, Deepen Mantri wrote:
> What is the benefit of assigning distinct LMAs to the non-overlay
> sections having overlapped VMAs? 

The changes to lma assignment made using overlays considerably
simpler.  In particular, sections following an overlay area now
don't need their LMAs set.

> Is there any way to generate an overlapping error for
> non-overlay/non-loadable
> sections (such as .bss section),if there VMAs get overlapped?

Assign the LMA as well as the VMA.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: No error for Linker Section Overlapping

[Alan Modra]

On Tue, Apr 17, 2007 at 04:41:48PM +0530, Deepen Mantri wrote:
> >> The changes to lma assignment made using overlays considerably 	
> >> simpler.  In particular, sections following an overlay area now	
> >> don't need their LMAs set.	
> 
> Yes, this is correct. However, it now seems to me that keyword 	
> "OVERLAY" has become redundant.

It always has been redundant.  See the "syntactic sugar" comment in
the ld info doc.

> Even if you do not use or intend 	
> to use it, the sections having overlapped VMAs are going to be 	
> considered as overlay sections.	

Well, yes.  After all, an overlapping VMA is the only difference
between an "overlay" section and a "normal" section as far as the
linker is concerned.  Prior to my change to LMA assignment, you
needed to specify the LMA on all overlay sections (or use the OVERLAY
keyword which did this for you), and all following sections (which the
OVERLAY keyword did not do).  Now you need to specify the LMA as well
if you specify VMA and *don't* want overlays, but see below.

> But can't we add an additional check, whether the sections having 	
> overlapped VMAs are overlay or not, before changing their LMAs?

Hmm, we could, by making the OVERLAY keyword affect the section type.
This should bring back the old behaviour for you but still give most
of the ease of use improvement for overlays.

ld/
	* ldlang.h (enum section_type): Add overlay_section.
	* ldlang.c (lang_add_section): Handle flags for overlay_section
	as per normal_section.
	(lang_size_sections_1): When setting lma, detect overlays by
	os->sectype rather than by looking for overlapping vmas.
	(lang_enter_overlay_section): Use overlay_section type.
	(lang_leave_overlay): Set first overlay section to normal.
ld/testsuite/
	* ld-spu/ovl.lnk: Use OVERLAY keyword.

Index: ld/ldlang.h
===================================================================
RCS file: /cvs/src/src/ld/ldlang.h,v
retrieving revision 1.72
diff -u -p -r1.72 ldlang.h
--- ld/ldlang.h	26 Mar 2007 11:10:44 -0000	1.72
+++ ld/ldlang.h	18 Apr 2007 02:10:00 -0000
@@ -108,6 +108,7 @@ typedef struct lang_output_statement_str
 enum section_type
 {
   normal_section,
+  overlay_section,
   noload_section,
   noalloc_section
 };
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.257
diff -u -p -r1.257 ldlang.c
--- ld/ldlang.c	10 Apr 2007 18:00:26 -0000	1.257
+++ ld/ldlang.c	18 Apr 2007 02:09:59 -0000
@@ -2040,6 +2040,7 @@ lang_add_section (lang_statement_list_ty
       switch (output->sectype)
 	{
 	case normal_section:
+	case overlay_section:
 	  break;
 	case noalloc_section:
 	  flags &= ~SEC_ALLOC;
@@ -4438,14 +4439,9 @@ lang_size_sections_1
 		  }
 		else
 		  {
-		    /* If the current vma overlaps the previous section,
-		       then set the current lma to that at the end of
-		       the previous section.  The previous section was
-		       probably an overlay.  */
-		    if ((dot >= last->vma
-			 && dot < last->vma + last->size)
-			|| (last->vma >= dot
-			    && last->vma < dot + os->bfd_section->size))
+		    /* If this is an overlay, set the current lma to that
+		       at the end of the previous section.  */
+		    if (os->sectype == overlay_section)
 		      lma = last->lma + last->size;
 
 		    /* Otherwise, keep the same lma to vma relationship
@@ -6392,7 +6388,7 @@ lang_enter_overlay_section (const char *
   struct overlay_list *n;
   etree_type *size;
 
-  lang_enter_output_section_statement (name, overlay_vma, normal_section,
+  lang_enter_output_section_statement (name, overlay_vma, overlay_section,
 				       0, overlay_subalign, 0, 0);
 
   /* If this is the first section, then base the VMA of future
@@ -6506,7 +6502,10 @@ lang_leave_overlay (etree_type *lma_expr
 	 The base address is not needed (and should be null) if
 	 an LMA region was specified.  */
       if (l->next == 0)
-	l->os->load_base = lma_expr;
+	{
+	  l->os->load_base = lma_expr;
+	  l->os->sectype = normal_section;
+	}
       if (phdrs != NULL && l->os->phdrs == NULL)
 	l->os->phdrs = phdrs;
 
Index: ld/testsuite/ld-spu/ovl.lnk
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-spu/ovl.lnk,v
retrieving revision 1.1
diff -u -p -r1.1 ovl.lnk
--- ld/testsuite/ld-spu/ovl.lnk	25 Oct 2006 06:49:21 -0000	1.1
+++ ld/testsuite/ld-spu/ovl.lnk	18 Apr 2007 02:10:03 -0000
@@ -3,10 +3,11 @@ SECTIONS
   . = SIZEOF_HEADERS;
   .text : { *(.text) *(.stub) }
 
-  . = 0x400;
-  .ov_a1 : { *(.ov_a1) }
-  .ov_a2 ADDR (.ov_a1) : { *(.ov_a2) }
-  . = ADDR (.ov_a1) + MAX (SIZEOF (.ov_a1), SIZEOF (.ov_a2));
+  OVERLAY 0x400 :
+  {
+    .ov_a1 { *(.ov_a1) }
+    .ov_a2 { *(.ov_a2) }
+  }
 
   .data : { *(.data) *(.ovtab) }
   .bss : { *(.bss) }

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: No error for Linker Section Overlapping

[Deepen Mantri]

On Wed, 18th April, 2007 13:23:57 +0930 Alan Modra wrote:	

> >> But can't we add an additional check, whether the sections having

> >>overlapped VMAs are overlay or not, before changing their LMAs?	

> Hmm, we could, by making the OVERLAY keyword affect the section type.	
> This should bring back the old behaviour for you but still give most	
> of the ease of use improvement for overlays.	

Thank you for the patch. Linker now generates an error when the VMAs of	
non-overlay sections overlap.	

But their are two issues which need to be handled:	
1. Error prints the LMA addresses instead of VMA addresses when VMAs of	
   the sections overlap. This might create confusion.	
2. Also the allocation of the LMA address to non-loadable sections 	
   (such as ".bss" section) is not prevented.	
   
I was able to deal with these issues by developing the following patch	
which is an addition to your's. I would like to have your comments on
it.	


ChangeLog:	
2007-04-19  Deepen Mantri  <Deepen.Mantri@kpitcummins.com>	

bfd/	
	* bfd-in2.h (struct bfd_section): Add an integer as a flag for 	
	  checking whether it's VMA has overlapped or not.	
	* bfd-in2.h (#define BFD_FAKE_SECTION): Initialise the 	
	  the above introduced VMA overlap flag also.	
ld/	
	* ldlang.c (lang_check_section_addresses): Check whether LMA is	
	  overlapping or VMA depending on the value of the vma overlap	
	  flag. For the latter case, print overlapping VMA addresses.	
	* ldlang.c (lang_size_sections_1): When setting lma, first
detect		  overlays by os->sectype. If sections are not overlays,
check		  whether their VMAs are overlapping. If yes, set the
vma overlap	 
	  flag of that section. Otherwise if that section is
non-loadable,	  set lma=vma else keep the same lma to vma relationship
as that of	  previous section.	 
	
Index: bfd/bfd-in2.h
===================================================================
--- binutils-061211_orig/bfd/bfd-in2.h	2006-12-29 12:39:33.000000000
+0530
+++ binutils-061211/bfd/bfd-in2.h	2007-04-19 19:00:15.000000000
+0530
@@ -1474,6 +1474,8 @@ typedef struct bfd_section
     struct bfd_link_order *link_order;
     struct bfd_section *s;
   } map_head, map_tail;
+
+  unsigned int vma_overlap_flag;
 } asection;
 
 /* These sections are global, and are managed by BFD.  The application
@@ -1632,8 +1634,8 @@ extern asection bfd_ind_section;
   /* symbol,                    symbol_ptr_ptr,                    */
\
      (struct bfd_symbol *) SYM, &SEC.symbol,
\
 
\
-  /* map_head, map_tail                                            */
\
-     { NULL }, { NULL }
\
+  /* map_head, map_tail, vma_overlap_flag                          */
\
+     { NULL }, { NULL },   0
\
     }
 void bfd_section_list_clear (bfd *);
=================================================================== 


Index: ld/ldlang.c
=================================================================== 
--- binutils-061211_orig/ld/ldlang.c	2006-12-29 12:39:30.000000000
+0530
+++ binutils-061211/ld/ldlang.c	2007-04-19 13:57:51.000000000 +0530
@@ -4159,10 +4160,15 @@ lang_check_section_addresses (void)
       s_start = bfd_section_lma (output_bfd, s);
       s_end = s_start + TO_ADDR (s->size) - 1;
 
-      /* Look for an overlap.  */
-      if (s_end >= os_start && s_start <= os_end)
-	einfo (_("%X%P: section %s [%V -> %V] overlaps section %s [%V ->
%V]\n"),
+      /* Look for LMA overlap.  */
+      if (s_end >= os_start && s_start <= os_end &&
!(s->vma_overlap_flag))
+	      
+	 einfo (_("%X%P: LMA Overlapping: section %s [%V -> %V] overlaps
section %s [%V -> %V]\n"),
 	       s->name, s_start, s_end, os->name, os_start, os_end);
+      /* Look for VMA overlap.  */
+      if (s->vma_overlap_flag)
+         einfo (_("%X%P: VMA Overlapping: section %s [%V -> %V]
overlaps section %s [%V -> %V]\n"),
+               s->name, s->vma,(s->vma + s->size), os->name, os->vma,
(os->vma + os->size));
     }
 
   free (sections);
@@ -4428,25 +4434,35 @@ lang_size_sections_1
 		  }
 		else
 		  {
-		    /* If the current vma overlaps the previous section,
-		       then set the current lma to that at the end of
-		       the previous section.  The previous section was
-		       probably an overlay.  */
-		    if ((dot >= last->vma
-			 && dot < last->vma + last->size)
-			|| (last->vma >= dot
-			    && last->vma < dot + os->bfd_section->size))
-		      lma = last->lma + last->size;
-
-		    /* Otherwise, keep the same lma to vma relationship
-		       as the previous section.  */
-		    else
-		      lma = dot + last->lma - last->vma;
-
-		    if (os->section_alignment != -1)
-		      lma = align_power (lma, os->section_alignment);
-		    os->bfd_section->lma = lma;
-		  }
+	             /* If this is an overlay, set the current lma to
that
+		        at the end of the previous section.  */
+		     if (os->sectype == overlay_section)
+			    lma = last->lma + last->size;
+		     else
+	             {		     
+		     	/* Check for the VMA overlapping. If it overlaps
then set 
+			   the vma_overlap_flag which will help to print
the error  */
+		     	if ((dot >= last->vma && dot < last->vma +
last->size)
+		           || (last->vma >= dot && last->vma < dot +
os->bfd_section->size))
+		        {	      
+		           os->bfd_section->vma_overlap_flag=1;

+			}
+		  	
+			/* Otherwise, keep the same lma to vma
relationship
+			    as the previous section.But do not change
the LMA=VMA 
+			    relationship for non-loadable sections(like
.bss section)*/
+
+			if(os->bfd_section->flags & SEC_LOAD)
+			      	lma = dot + last->lma - last->vma;
+			else
+				lma = dot;      
+		        
+			if (os->section_alignment != -1)
+		     	  lma = align_power (lma,
os->section_alignment);
+			
+		    	os->bfd_section->lma = lma;
+		     }
+	           }
 	      }
 	    os->processed_lma = TRUE;
 
===================================================================	


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.	
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: No error for Linker Section Overlapping

[Alan Modra]

On Thu, Apr 19, 2007 at 09:12:23PM +0530, Deepen Mantri wrote:
> 1. Error prints the LMA addresses instead of VMA addresses when VMAs of
>    the sections overlap. This might create confusion.	

VMA == LMA except when using overlays or when assigning LMA in the
linker script.  I don't think the error message is worth changing.

> 2. Also the allocation of the LMA address to non-loadable sections 	
>    (such as ".bss" section) is not prevented.	

Why is this a problem?  Changing this as you have done will break
other code in the linker, eg. _bfd_elf_map_sections_to_segments.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: No error for Linker Section Overlapping

[Deepen Mantri]

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.

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

Re: No error for Linker Section Overlapping

[Alan Modra]

On Mon, Apr 23, 2007 at 08:25:15PM +0530, Deepen Mantri wrote:
> Could you please explain me in detail, what could be the other
> consequences
> of the modifications done? 

Changing the lma to vma relationship will put .bss into a different
load segment.  Usually you wouldn't want that to happen, because it
needlessly creates a new segment.

You do apparently want that to happen.  Please just add
"AT(ADDR(.bss))" to your .bss output section description.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: No error for Linker Section Overlapping

[Deepen Mantri]

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

>> 1. Error prints the LMA addresses instead of VMA addresses
>>    when VMAs of the sections overlap. This might create 
>>    confusion.	
>  VMA == LMA except when using overlays or when assigning 
>  LMA in the linker script.  I don't think the error message
>  is worth changing.

Being precise in printing the source of error would help the
user in understanding and fixing the problem quickly, isn't it?

On Tue, 24th April 2007 at 01:01:15 +0930 Alan Modra wrote:

> Changing the lma to vma relationship will put .bss into a 
> different load segment. Usually you wouldn't want that to 
> happen, because it needlessly creates a new segment.

Considering the linker script in my preceeding reply, a new 
segment for .bss section is expected and is rightly created 
because of the following condition present in the 
"_bfd_elf_map_sections_to_segments" function.

//////////////////////////////////////////////////////////////
else if (last_hdr->lma - last_hdr->vma != hdr->lma - hdr->vma)
{
     /* If this section has a different relation between the
        virtual address and the load address, then we need a 
        new segment.  */
     new_segment = TRUE;
}
/////////////////////////////////////////////////////////////
The .bss section was assigned a new segment till binutils 2.16.92.
From binutils 2.17 onwards .bss section is not going in a new 
segment because it's LMA is following the .data section and thus
resulting in failure of the above condition.


> Please just add "AT(ADDR(.bss))" to your .bss output 
> section description.

Adding "AT(ADDR(.bss))" seems to be a workaround. I guess, it 
will be always better to fix the problem inside the linker 
itself. Please comment.

Only concern is that the additions done should not result in
unexpected failures in other parts of linker code which, as far as 
my understanding goes, is not happening.
If you foresee any fundamental change happening in the 
linker code due to my patch, could you please share it with me?


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,07	
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~