public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* NOLOAD problem with binutils 2.16.92
@ 2006-07-26 10:01 Ashutosh Yeole
  2006-07-26 20:11 ` Ramana Radhakrishnan
  2006-07-28  7:32 ` Ben Elliston
  0 siblings, 2 replies; 9+ messages in thread
From: Ashutosh Yeole @ 2006-07-26 10:01 UTC (permalink / raw)
  To: binutils

Hi,
I had posted a problem related to binutils 2.16.92

Please refer to the following link for the posted problem,
http://sourceware.org/ml/binutils/2006-07/msg00225.html

After further investigation, I found that this problem also exists for
ARM and m32r targets also.

Kindly let me know your comments on the same.

Regards,
Ashutosh Yeole
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 June 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-26 10:01 NOLOAD problem with binutils 2.16.92 Ashutosh Yeole
@ 2006-07-26 20:11 ` Ramana Radhakrishnan
  2006-07-28  7:32 ` Ben Elliston
  1 sibling, 0 replies; 9+ messages in thread
From: Ramana Radhakrishnan @ 2006-07-26 20:11 UTC (permalink / raw)
  To: Ashutosh Yeole; +Cc: binutils

This came up for discussion sometime earlier too ... 

http://sources.redhat.com/ml/binutils/2006-03/msg00189.html

-Ramana

On Wed, 2006-07-26 at 15:31 +0530, Ashutosh Yeole wrote:
> Hi,
> I had posted a problem related to binutils 2.16.92
> 
> Please refer to the following link for the posted problem,
> http://sourceware.org/ml/binutils/2006-07/msg00225.html
> 
> After further investigation, I found that this problem also exists for
> ARM and m32r targets also.
> 
> Kindly let me know your comments on the same.
> 
> Regards,
> Ashutosh Yeole
> 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 June 1, 2006.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-26 10:01 NOLOAD problem with binutils 2.16.92 Ashutosh Yeole
  2006-07-26 20:11 ` Ramana Radhakrishnan
@ 2006-07-28  7:32 ` Ben Elliston
  2006-07-31 13:21   ` Ashutosh Yeole
  1 sibling, 1 reply; 9+ messages in thread
From: Ben Elliston @ 2006-07-28  7:32 UTC (permalink / raw)
  To: Ashutosh Yeole; +Cc: binutils

> I had posted a problem related to binutils 2.16.92
> 
> Please refer to the following link for the posted problem,
> http://sourceware.org/ml/binutils/2006-07/msg00225.html

> After further investigation, I found that this problem also exists for
> ARM and m32r targets also.

Before we go much further, have you tested with CVS binutils?

Cheers, Ben

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: NOLOAD problem with binutils 2.16.92
  2006-07-28  7:32 ` Ben Elliston
@ 2006-07-31 13:21   ` Ashutosh Yeole
  2006-07-31 14:54     ` H. J. Lu
  2006-07-31 20:03     ` H. J. Lu
  0 siblings, 2 replies; 9+ messages in thread
From: Ashutosh Yeole @ 2006-07-31 13:21 UTC (permalink / raw)
  To: binutils; +Cc: Ben Elliston

Hi,
I have tried this problem using the latest snapshot of binutils dated
30th July 2006, however the same problem still exists. With this 
snapshot, I tested for SH as well as H8 targets.

http://lists.gnu.org/archive/html/bug-binutils/2006-07/msg00041.html
(Link to the actual problem)

I have further investigated and developed a workaround patch which
solves the NOLOAD problem. In function ' elf_fake_sections' from 
elf.c,  "this_hdr" is populated. However, value for section header 
(sh_type) is assigned only if "this_hdr->sh_type" is NULL. However, 
I have found that, even for section with "NOLOAD" attribute, the 
value of section header (this_hdr->sh_type) is 'SHT_PROGBITS' instead
of 'SHT_NOBITS' or 'SHT_NULL'. In case, it is SHT_NULL, then the 
value for section type is found depending upon the other flags from 
'asect->flags' (SEC_NEVER_LOAD). 
Therefore, I have added a extra check to see if the 'SHT_PROGBITS' is
correct assignment in earlier processing or not.

No new regressions found with the following patch.

ChangeLog:

2006-07-31   Ashutosh Yeole <ashutoshy@kpitcummins.com>

	  * Binutils/bfd/elf.c (elf_fake_sections): Condition added for
	  section header type.

========================================================================
===
--- binutils-2.16.92/bfd/elf.c.orig     2006-03-16 17:50:15.000000000
+0530
+++ binutils-2.16.92/bfd/elf.c  2006-07-31 15:41:18.000000000 +0530
@@ -2695,7 +2695,7 @@ elf_fake_sections (bfd *abfd, asection *

   /* If the section type is unspecified, we set it based on
      asect->flags.  */
-  if (this_hdr->sh_type == SHT_NULL)
+  if ((this_hdr->sh_type == SHT_NULL) || (this_hdr->sh_type ==
SHT_PROGBITS))
     {
       if ((asect->flags & SEC_GROUP) != 0)
        this_hdr->sh_type = SHT_GROUP;
========================================================================
===

However I am not very sure about the patch and I understand it may be
fixed somewhere else. I would like to know your comments on the same.

Regards,
Ashutosh Yeole
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 June 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Regards,
Ashutosh A Yeole
System Executive - SSG | KPIT Cummins Infosystems Ltd.| Ph: +91 020 2538
2358 Ext: 420

-----Original Message-----
From: Ben Elliston [mailto:bje@au1.ibm.com] 
Sent: Friday, July 28, 2006 1:04 PM
To: Ashutosh Yeole
Cc: binutils@sourceware.org
Subject: Re: NOLOAD problem with binutils 2.16.92

> I had posted a problem related to binutils 2.16.92
> 
> Please refer to the following link for the posted problem,
> http://sourceware.org/ml/binutils/2006-07/msg00225.html

> After further investigation, I found that this problem also exists for
> ARM and m32r targets also.

Before we go much further, have you tested with CVS binutils?

Cheers, Ben

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-31 13:21   ` Ashutosh Yeole
@ 2006-07-31 14:54     ` H. J. Lu
  2006-07-31 20:03     ` H. J. Lu
  1 sibling, 0 replies; 9+ messages in thread
From: H. J. Lu @ 2006-07-31 14:54 UTC (permalink / raw)
  To: Ashutosh Yeole; +Cc: binutils, Ben Elliston

On Mon, Jul 31, 2006 at 06:51:17PM +0530, Ashutosh Yeole wrote:
> Hi,
> I have tried this problem using the latest snapshot of binutils dated
> 30th July 2006, however the same problem still exists. With this 
> snapshot, I tested for SH as well as H8 targets.
> 
> http://lists.gnu.org/archive/html/bug-binutils/2006-07/msg00041.html
> (Link to the actual problem)

Please open a bug report at:

http://www.sourceware.org/bugzilla/

>    /* If the section type is unspecified, we set it based on
>       asect->flags.  */
> -  if (this_hdr->sh_type == SHT_NULL)
> +  if ((this_hdr->sh_type == SHT_NULL) || (this_hdr->sh_type ==
> SHT_PROGBITS))
>      {
>        if ((asect->flags & SEC_GROUP) != 0)
>         this_hdr->sh_type = SHT_GROUP;

It doesn't look right.

> 
> However I am not very sure about the patch and I understand it may be
> fixed somewhere else. I would like to know your comments on the same.
> 

You need to find where and why this_hdr->sh_type is set to
SHT_PROGBITS in the first place.


H.J.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-31 13:21   ` Ashutosh Yeole
  2006-07-31 14:54     ` H. J. Lu
@ 2006-07-31 20:03     ` H. J. Lu
  2006-07-31 23:45       ` Alan Modra
  1 sibling, 1 reply; 9+ messages in thread
From: H. J. Lu @ 2006-07-31 20:03 UTC (permalink / raw)
  To: Ashutosh Yeole; +Cc: binutils, Ben Elliston

On Mon, Jul 31, 2006 at 06:51:17PM +0530, Ashutosh Yeole wrote:
> Hi,
> I have tried this problem using the latest snapshot of binutils dated
> 30th July 2006, however the same problem still exists. With this 
> snapshot, I tested for SH as well as H8 targets.
> 
> http://lists.gnu.org/archive/html/bug-binutils/2006-07/msg00041.html
> (Link to the actual problem)
> 
> I have further investigated and developed a workaround patch which
> solves the NOLOAD problem. In function ' elf_fake_sections' from 
> elf.c,  "this_hdr" is populated. However, value for section header 
> (sh_type) is assigned only if "this_hdr->sh_type" is NULL. However, 
> I have found that, even for section with "NOLOAD" attribute, the 
> value of section header (this_hdr->sh_type) is 'SHT_PROGBITS' instead
> of 'SHT_NOBITS' or 'SHT_NULL'. In case, it is SHT_NULL, then the 
> value for section type is found depending upon the other flags from 
> 'asect->flags' (SEC_NEVER_LOAD). 
> Therefore, I have added a extra check to see if the 'SHT_PROGBITS' is
> correct assignment in earlier processing or not.
> 

The problem is linker uses bfd_make_section first and the changes
the section flags later. This patch seems to work.


H.J.
----
2006-07-31  H.J. Lu  <hongjiu.lu@intel.com>

	* ldlang.c (init_os): Add flags. Replace bfd_make_section with
	bfd_make_section_with_flags.
	(exp_init_os): Updated.
	(lang_add_section): Call init_os with flags.
	(map_input_to_output_sections): Likewise.

--- ld/ldlang.c.flags	2006-07-28 13:58:01.000000000 -0700
+++ ld/ldlang.c	2006-07-31 12:53:34.000000000 -0700
@@ -1859,7 +1859,8 @@ sort_def_symbol (hash_entry, info)
 /* Initialize an output section.  */
 
 static void
-init_os (lang_output_section_statement_type *s, asection *isec)
+init_os (lang_output_section_statement_type *s, asection *isec,
+	 flagword flags)
 {
   if (s->bfd_section != NULL)
     return;
@@ -1869,7 +1870,8 @@ init_os (lang_output_section_statement_t
 
   s->bfd_section = bfd_get_section_by_name (output_bfd, s->name);
   if (s->bfd_section == NULL)
-    s->bfd_section = bfd_make_section (output_bfd, s->name);
+    s->bfd_section = bfd_make_section_with_flags (output_bfd, s->name,
+						  flags);
   if (s->bfd_section == NULL)
     {
       einfo (_("%P%F: output format %s cannot represent section called %s\n"),
@@ -1947,7 +1949,7 @@ exp_init_os (etree_type *exp)
 
 	    os = lang_output_section_find (exp->name.name);
 	    if (os != NULL && os->bfd_section == NULL)
-	      init_os (os, NULL);
+	      init_os (os, NULL, 0);
 	  }
 	}
       break;
@@ -2022,8 +2024,32 @@ lang_add_section (lang_statement_list_ty
       lang_input_section_type *new;
       flagword flags;
 
+      flags = section->flags;
+
+      /* We don't copy the SEC_NEVER_LOAD flag from an input section
+	 to an output section, because we want to be able to include a
+	 SEC_NEVER_LOAD section in the middle of an otherwise loaded
+	 section (I don't know why we want to do this, but we do).
+	 build_link_order in ldwrite.c handles this case by turning
+	 the embedded SEC_NEVER_LOAD section into a fill.  */
+
+      flags &= ~ SEC_NEVER_LOAD;
+
+      switch (output->sectype)
+	{
+	case normal_section:
+	  break;
+	case noalloc_section:
+	  flags &= ~SEC_ALLOC;
+	  break;
+	case noload_section:
+	  flags &= ~SEC_LOAD;
+	  flags |= SEC_NEVER_LOAD;
+	  break;
+	}
+
       if (output->bfd_section == NULL)
-	init_os (output, section);
+	init_os (output, section, flags);
 
       first = ! output->bfd_section->linker_has_input;
       output->bfd_section->linker_has_input = 1;
@@ -2047,17 +2073,6 @@ lang_add_section (lang_statement_list_ty
       new->section = section;
       section->output_section = output->bfd_section;
 
-      flags = section->flags;
-
-      /* We don't copy the SEC_NEVER_LOAD flag from an input section
-	 to an output section, because we want to be able to include a
-	 SEC_NEVER_LOAD section in the middle of an otherwise loaded
-	 section (I don't know why we want to do this, but we do).
-	 build_link_order in ldwrite.c handles this case by turning
-	 the embedded SEC_NEVER_LOAD section into a fill.  */
-
-      flags &= ~ SEC_NEVER_LOAD;
-
       /* If final link, don't copy the SEC_LINK_ONCE flags, they've
 	 already been processed.  One reason to do this is that on pe
 	 format targets, .text$foo sections go into .text and it's odd
@@ -2094,19 +2109,6 @@ lang_add_section (lang_statement_list_ty
       if ((section->flags & SEC_READONLY) == 0)
 	output->bfd_section->flags &= ~SEC_READONLY;
 
-      switch (output->sectype)
-	{
-	case normal_section:
-	  break;
-	case noalloc_section:
-	  output->bfd_section->flags &= ~SEC_ALLOC;
-	  break;
-	case noload_section:
-	  output->bfd_section->flags &= ~SEC_LOAD;
-	  output->bfd_section->flags |= SEC_NEVER_LOAD;
-	  break;
-	}
-
       /* Copy over SEC_SMALL_DATA.  */
       if (section->flags & SEC_SMALL_DATA)
 	output->bfd_section->flags |= SEC_SMALL_DATA;
@@ -3202,6 +3204,8 @@ map_input_to_output_sections
   (lang_statement_union_type *s, const char *target,
    lang_output_section_statement_type *os)
 {
+  flagword flags;
+
   for (; s != NULL; s = s->header.next)
     {
       switch (s->header.type)
@@ -3251,13 +3255,15 @@ map_input_to_output_sections
 	  /* Make sure that any sections mentioned in the expression
 	     are initialized.  */
 	  exp_init_os (s->data_statement.exp);
-	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	  flags = SEC_HAS_CONTENTS;
 	  /* The output section gets contents, and then we inspect for
 	     any flags set in the input script which override any ALLOC.  */
-	  os->bfd_section->flags |= SEC_HAS_CONTENTS;
 	  if (!(os->flags & SEC_NEVER_LOAD))
-	    os->bfd_section->flags |= SEC_ALLOC | SEC_LOAD;
+	    flags |= SEC_ALLOC | SEC_LOAD;
+	  if (os->bfd_section == NULL)
+	    init_os (os, NULL, flags);
+	  else
+	    os->bfd_section->flags |= flags;
 	  break;
 	case lang_input_section_enum:
 	  break;
@@ -3267,11 +3273,11 @@ map_input_to_output_sections
 	case lang_padding_statement_enum:
 	case lang_input_statement_enum:
 	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	    init_os (os, NULL, 0);
 	  break;
 	case lang_assignment_statement_enum:
 	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	    init_os (os, NULL, 0);
 
 	  /* Make sure that any sections mentioned in the assignment
 	     are initialized.  */
@@ -3299,7 +3305,7 @@ map_input_to_output_sections
 		   (s->address_statement.section_name));
 
 	      if (aos->bfd_section == NULL)
-		init_os (aos, NULL);
+		init_os (aos, NULL, 0);
 	      aos->addr_tree = s->address_statement.address;
 	    }
 	  break;

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-31 20:03     ` H. J. Lu
@ 2006-07-31 23:45       ` Alan Modra
  2006-08-01 17:43         ` H. J. Lu
  0 siblings, 1 reply; 9+ messages in thread
From: Alan Modra @ 2006-07-31 23:45 UTC (permalink / raw)
  To: H. J. Lu; +Cc: Ashutosh Yeole, binutils, Ben Elliston

On Mon, Jul 31, 2006 at 01:03:18PM -0700, H. J. Lu wrote:
> 2006-07-31  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* ldlang.c (init_os): Add flags. Replace bfd_make_section with
> 	bfd_make_section_with_flags.
> 	(exp_init_os): Updated.
> 	(lang_add_section): Call init_os with flags.
> 	(map_input_to_output_sections): Likewise.

The idea looks OK to me.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: NOLOAD problem with binutils 2.16.92
  2006-07-31 23:45       ` Alan Modra
@ 2006-08-01 17:43         ` H. J. Lu
  0 siblings, 0 replies; 9+ messages in thread
From: H. J. Lu @ 2006-08-01 17:43 UTC (permalink / raw)
  To: Ashutosh Yeole, binutils, Ben Elliston

On Tue, Aug 01, 2006 at 09:15:40AM +0930, Alan Modra wrote:
> On Mon, Jul 31, 2006 at 01:03:18PM -0700, H. J. Lu wrote:
> > 2006-07-31  H.J. Lu  <hongjiu.lu@intel.com>
> > 
> > 	* ldlang.c (init_os): Add flags. Replace bfd_make_section with
> > 	bfd_make_section_with_flags.
> > 	(exp_init_os): Updated.
> > 	(lang_add_section): Call init_os with flags.
> > 	(map_input_to_output_sections): Likewise.
> 
> The idea looks OK to me.
> 

I am checking this patch with a testcase.


H.J.
---
ld/

2006-08-01  H.J. Lu  <hongjiu.lu@intel.com>

	* ldlang.c (init_os): Add flags. Replace bfd_make_section with
	bfd_make_section_with_flags.
	(exp_init_os): Updated.
	(lang_add_section): Call init_os with flags.
	(map_input_to_output_sections): Likewise.

ld/testsuite/

2006-08-01  H.J. Lu  <hongjiu.lu@intel.com>

	* ld-elf/noload-1.d: New.
	* ld-elf/noload-1.s: Likewise.
	* ld-elf/noload-1.t: Likewise.

--- ld/ldlang.c.noload	2006-07-28 13:58:01.000000000 -0700
+++ ld/ldlang.c	2006-08-01 10:38:23.000000000 -0700
@@ -1859,7 +1859,8 @@ sort_def_symbol (hash_entry, info)
 /* Initialize an output section.  */
 
 static void
-init_os (lang_output_section_statement_type *s, asection *isec)
+init_os (lang_output_section_statement_type *s, asection *isec,
+	 flagword flags)
 {
   if (s->bfd_section != NULL)
     return;
@@ -1869,7 +1870,8 @@ init_os (lang_output_section_statement_t
 
   s->bfd_section = bfd_get_section_by_name (output_bfd, s->name);
   if (s->bfd_section == NULL)
-    s->bfd_section = bfd_make_section (output_bfd, s->name);
+    s->bfd_section = bfd_make_section_with_flags (output_bfd, s->name,
+						  flags);
   if (s->bfd_section == NULL)
     {
       einfo (_("%P%F: output format %s cannot represent section called %s\n"),
@@ -1947,7 +1949,7 @@ exp_init_os (etree_type *exp)
 
 	    os = lang_output_section_find (exp->name.name);
 	    if (os != NULL && os->bfd_section == NULL)
-	      init_os (os, NULL);
+	      init_os (os, NULL, 0);
 	  }
 	}
       break;
@@ -2022,8 +2024,32 @@ lang_add_section (lang_statement_list_ty
       lang_input_section_type *new;
       flagword flags;
 
+      flags = section->flags;
+
+      /* We don't copy the SEC_NEVER_LOAD flag from an input section
+	 to an output section, because we want to be able to include a
+	 SEC_NEVER_LOAD section in the middle of an otherwise loaded
+	 section (I don't know why we want to do this, but we do).
+	 build_link_order in ldwrite.c handles this case by turning
+	 the embedded SEC_NEVER_LOAD section into a fill.  */
+
+      flags &= ~ SEC_NEVER_LOAD;
+
+      switch (output->sectype)
+	{
+	case normal_section:
+	  break;
+	case noalloc_section:
+	  flags &= ~SEC_ALLOC;
+	  break;
+	case noload_section:
+	  flags &= ~SEC_LOAD;
+	  flags |= SEC_NEVER_LOAD;
+	  break;
+	}
+
       if (output->bfd_section == NULL)
-	init_os (output, section);
+	init_os (output, section, flags);
 
       first = ! output->bfd_section->linker_has_input;
       output->bfd_section->linker_has_input = 1;
@@ -2047,17 +2073,6 @@ lang_add_section (lang_statement_list_ty
       new->section = section;
       section->output_section = output->bfd_section;
 
-      flags = section->flags;
-
-      /* We don't copy the SEC_NEVER_LOAD flag from an input section
-	 to an output section, because we want to be able to include a
-	 SEC_NEVER_LOAD section in the middle of an otherwise loaded
-	 section (I don't know why we want to do this, but we do).
-	 build_link_order in ldwrite.c handles this case by turning
-	 the embedded SEC_NEVER_LOAD section into a fill.  */
-
-      flags &= ~ SEC_NEVER_LOAD;
-
       /* If final link, don't copy the SEC_LINK_ONCE flags, they've
 	 already been processed.  One reason to do this is that on pe
 	 format targets, .text$foo sections go into .text and it's odd
@@ -2094,19 +2109,6 @@ lang_add_section (lang_statement_list_ty
       if ((section->flags & SEC_READONLY) == 0)
 	output->bfd_section->flags &= ~SEC_READONLY;
 
-      switch (output->sectype)
-	{
-	case normal_section:
-	  break;
-	case noalloc_section:
-	  output->bfd_section->flags &= ~SEC_ALLOC;
-	  break;
-	case noload_section:
-	  output->bfd_section->flags &= ~SEC_LOAD;
-	  output->bfd_section->flags |= SEC_NEVER_LOAD;
-	  break;
-	}
-
       /* Copy over SEC_SMALL_DATA.  */
       if (section->flags & SEC_SMALL_DATA)
 	output->bfd_section->flags |= SEC_SMALL_DATA;
@@ -3202,6 +3204,8 @@ map_input_to_output_sections
   (lang_statement_union_type *s, const char *target,
    lang_output_section_statement_type *os)
 {
+  flagword flags;
+
   for (; s != NULL; s = s->header.next)
     {
       switch (s->header.type)
@@ -3251,13 +3255,15 @@ map_input_to_output_sections
 	  /* Make sure that any sections mentioned in the expression
 	     are initialized.  */
 	  exp_init_os (s->data_statement.exp);
-	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	  flags = SEC_HAS_CONTENTS;
 	  /* The output section gets contents, and then we inspect for
 	     any flags set in the input script which override any ALLOC.  */
-	  os->bfd_section->flags |= SEC_HAS_CONTENTS;
 	  if (!(os->flags & SEC_NEVER_LOAD))
-	    os->bfd_section->flags |= SEC_ALLOC | SEC_LOAD;
+	    flags |= SEC_ALLOC | SEC_LOAD;
+	  if (os->bfd_section == NULL)
+	    init_os (os, NULL, flags);
+	  else
+	    os->bfd_section->flags |= flags;
 	  break;
 	case lang_input_section_enum:
 	  break;
@@ -3267,11 +3273,11 @@ map_input_to_output_sections
 	case lang_padding_statement_enum:
 	case lang_input_statement_enum:
 	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	    init_os (os, NULL, 0);
 	  break;
 	case lang_assignment_statement_enum:
 	  if (os != NULL && os->bfd_section == NULL)
-	    init_os (os, NULL);
+	    init_os (os, NULL, 0);
 
 	  /* Make sure that any sections mentioned in the assignment
 	     are initialized.  */
@@ -3299,7 +3305,7 @@ map_input_to_output_sections
 		   (s->address_statement.section_name));
 
 	      if (aos->bfd_section == NULL)
-		init_os (aos, NULL);
+		init_os (aos, NULL, 0);
 	      aos->addr_tree = s->address_statement.address;
 	    }
 	  break;
--- ld/testsuite/ld-elf/noload-1.d.noload	2006-08-01 10:34:41.000000000 -0700
+++ ld/testsuite/ld-elf/noload-1.d	2006-08-01 10:34:15.000000000 -0700
@@ -0,0 +1,7 @@
+#source: noload-1.s
+#ld: -T noload-1.t
+#readelf: -S --wide
+
+#...
+  \[[ 0-9]+\] TEST[ \t]+NOBITS[ \t0-9a-f]+WA.*
+#pass
--- ld/testsuite/ld-elf/noload-1.s.noload	2006-08-01 10:34:41.000000000 -0700
+++ ld/testsuite/ld-elf/noload-1.s	2006-08-01 10:28:24.000000000 -0700
@@ -0,0 +1,2 @@
+	.section TEST,"aw",%progbits
+	.byte 0
--- ld/testsuite/ld-elf/noload-1.t.noload	2006-08-01 10:34:41.000000000 -0700
+++ ld/testsuite/ld-elf/noload-1.t	2006-08-01 10:30:04.000000000 -0700
@@ -0,0 +1,8 @@
+SECTIONS
+{
+  TEST (NOLOAD) :
+  {
+    *(TEST)
+  }
+  /DISCARD/ : { *(.*) }
+}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* NOLOAD problem with binutils 2.16.92
@ 2006-07-18 12:54 Ashutosh Yeole
  0 siblings, 0 replies; 9+ messages in thread
From: Ashutosh Yeole @ 2006-07-18 12:54 UTC (permalink / raw)
  To: binutils


Hi,

I am facing a problem in binutils 2.16.92.

Please refer to the code and the linker script below.

CODE:
-----

char ldTest __attribute__ ((section("TEST")));

int main(void)
{
	ldTest = 5;
}

LINKER SCRIPT:
--------------
	.bss :
	{
		_bss = .;
		*(.bss)
		*(COMMON)
		_ebss = .;
		_end = .;
	}
	.stack 0x00083800 :
	{
		_stack = .;
	}
	TEST 0x00FFEC00 (NOLOAD) :
	{
		*(TEST)
	}


In the Linker script the user defined section "TEST" is assigned as
NOLOAD. Here it is expected that "TEST" section to behave same as ".bss"
section.
When above code is linked using the binutils 2.16.92, "TEST" section is
assigned PROGBITS type whereas ".bss" section is assigned NOBITS type.

But when the same code and linker script are linked using binutils
2.16.1 then the "TEST" and ".bss" sections are assigned as NOBITS type.

Below are the results observed:

Section Headers:
[Nr] Name   Type         Addr     Off    Size   ES Flg Lk Inf Al
	.
	.
[ 8] .bss   NOBITS       000827c4 00203c 00002a 00  WA  0   0  4
[ 9] TEST   PROGBITS     00ffec00 00203c 000001 00  WA  0   0  1
	.
	.
	.

TEST section is assigned PROGBITS instead of NOBITS when linked using ld
(binutils 2.16.92).

Section Headers:
[Nr] Name   Type         Addr     Off    Size   ES Flg Lk Inf Al
	.
	.
[ 9] .bss   NOBITS       00082740 001de6 000046 00  WA  0   0  4
[10] TEST   NOBITS       00ffec00 001de6 000001 00  WA  0   0  1
	.
	.
	.
TEST section is assigned NOBITS when linked using ld (binutils 2.16.1).

This problem exists on both SH and H8/300 targets.

Please let me know why this is happening and any solution to fix this
problem.

The same bug has been reported on,
http://lists.gnu.org/archive/html/bug-binutils/2006-07/msg00041.html
however we did not receive any reply to the same. Can anyone help us to
resolve this issue?

Regards,
Ashutosh Yeole
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 June 1, 2006.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~	

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2006-08-01 17:43 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-07-26 10:01 NOLOAD problem with binutils 2.16.92 Ashutosh Yeole
2006-07-26 20:11 ` Ramana Radhakrishnan
2006-07-28  7:32 ` Ben Elliston
2006-07-31 13:21   ` Ashutosh Yeole
2006-07-31 14:54     ` H. J. Lu
2006-07-31 20:03     ` H. J. Lu
2006-07-31 23:45       ` Alan Modra
2006-08-01 17:43         ` H. J. Lu
  -- strict thread matches above, loose matches on Subject: below --
2006-07-18 12:54 Ashutosh Yeole

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