* No error for Linker Section Overlapping @ 2007-04-12 13:50 Deepen Mantri 2007-04-14 1:42 ` Alan Modra 0 siblings, 1 reply; 9+ messages in thread From: Deepen Mantri @ 2007-04-12 13:50 UTC (permalink / raw) To: binutils; +Cc: 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: No error for Linker Section Overlapping 2007-04-12 13:50 No error for Linker Section Overlapping Deepen Mantri @ 2007-04-14 1:42 ` Alan Modra 2007-04-17 13:17 ` Deepen Mantri 0 siblings, 1 reply; 9+ messages in thread From: Alan Modra @ 2007-04-14 1:42 UTC (permalink / raw) To: Deepen Mantri; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: No error for Linker Section Overlapping 2007-04-14 1:42 ` Alan Modra @ 2007-04-17 13:17 ` Deepen Mantri 2007-04-18 4:10 ` Alan Modra 0 siblings, 1 reply; 9+ messages in thread From: Deepen Mantri @ 2007-04-17 13:17 UTC (permalink / raw) To: Alan Modra; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: No error for Linker Section Overlapping 2007-04-17 13:17 ` Deepen Mantri @ 2007-04-18 4:10 ` Alan Modra 2007-04-19 17:05 ` Deepen Mantri 0 siblings, 1 reply; 9+ messages in thread From: Alan Modra @ 2007-04-18 4:10 UTC (permalink / raw) To: Deepen Mantri; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: No error for Linker Section Overlapping 2007-04-18 4:10 ` Alan Modra @ 2007-04-19 17:05 ` Deepen Mantri 2007-04-21 5:01 ` Alan Modra 0 siblings, 1 reply; 9+ messages in thread From: Deepen Mantri @ 2007-04-19 17:05 UTC (permalink / raw) To: Alan Modra; +Cc: binutils 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: No error for Linker Section Overlapping 2007-04-19 17:05 ` Deepen Mantri @ 2007-04-21 5:01 ` Alan Modra 2007-04-23 15:08 ` Deepen Mantri 0 siblings, 1 reply; 9+ messages in thread From: Alan Modra @ 2007-04-21 5:01 UTC (permalink / raw) To: Deepen Mantri; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: No error for Linker Section Overlapping 2007-04-21 5:01 ` Alan Modra @ 2007-04-23 15:08 ` Deepen Mantri 2007-04-23 15:32 ` Alan Modra 0 siblings, 1 reply; 9+ messages in thread From: Deepen Mantri @ 2007-04-23 15:08 UTC (permalink / raw) To: Alan Modra; +Cc: binutils 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: No error for Linker Section Overlapping 2007-04-23 15:08 ` Deepen Mantri @ 2007-04-23 15:32 ` Alan Modra 2007-04-24 10:59 ` Deepen Mantri 0 siblings, 1 reply; 9+ messages in thread From: Alan Modra @ 2007-04-23 15:32 UTC (permalink / raw) To: Deepen Mantri; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: No error for Linker Section Overlapping 2007-04-23 15:32 ` Alan Modra @ 2007-04-24 10:59 ` Deepen Mantri 0 siblings, 0 replies; 9+ messages in thread From: Deepen Mantri @ 2007-04-24 10:59 UTC (permalink / raw) To: Alan Modra; +Cc: binutils 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-04-24 10:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-04-12 13:50 No error for Linker Section Overlapping Deepen Mantri 2007-04-14 1:42 ` Alan Modra 2007-04-17 13:17 ` Deepen Mantri 2007-04-18 4:10 ` Alan Modra 2007-04-19 17:05 ` Deepen Mantri 2007-04-21 5:01 ` Alan Modra 2007-04-23 15:08 ` Deepen Mantri 2007-04-23 15:32 ` Alan Modra 2007-04-24 10:59 ` Deepen Mantri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).