public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: Nick Clifton <nickc@redhat.com>
Cc: binutils@sources.redhat.com
Subject: Re: PATCH: Don't use section name to set ELF section data
Date: Fri, 25 Jul 2003 17:59:00 -0000	[thread overview]
Message-ID: <20030725175940.GA940@lucon.org> (raw)
In-Reply-To: <20030725174307.GA629@lucon.org>

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Fri, Jul 25, 2003 at 10:43:07AM -0700, H. J. Lu wrote:
> On Fri, Jul 25, 2003 at 09:10:18AM -0700, H. J. Lu wrote:
> > On Fri, Jul 25, 2003 at 07:38:06AM -0700, H. J. Lu wrote:
> > > On Fri, Jul 25, 2003 at 01:25:31PM +0100, Nick Clifton wrote:
> > > > Hi H.J.
> > > > 
> > > > > Here is the new patch. It caused no regressions on all targets
> > > > > affected. It fixed an ELF/ppc64 bug.
> > > > 
> > > > Excellent.
> > > 
> > > ...
> > > 
> > > > Approved - please apply.
> > > > 
> > > 
> > > Done. I made a small change. I used
> > > 
> > >   if (! BFD_SEND ((B), _new_section_hook, ((B), (S)))) \
> > > 
> > > instead of
> > > 
> > >   if (!_bfd_elf_new_section_hook ((B), (S)))                  \
> > >  
> > 
> > My patch mishandled the case:
> > 
> > 	.section .foo,"aw",@nobits
> > 
> > I checked in the following patch as an obvious fix.
> > 
> 
> It is not enough. "ld -r" is broken with
> 
> 	.section .foo,"aw",@nobits
> 	.space 20
> 
> Here is a patch.
> 
> 

It is still not enough. We shouldn't abort on processor specific
section types.


H.J.

[-- Attachment #2: binutils-type-fix.patch --]
[-- Type: text/plain, Size: 2399 bytes --]

bfd/

2003-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* elf.c (_bfd_elf_new_section_hook): Set the default section
	type to SHT_NULL.
	(elf_fake_sections): Set the section type based on asect->flags
	if it is SHT_NULL. Don't abort on processor specific section
	types.

gas/

2003-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* config/obj-elf.c (obj_elf_change_section): Update
	elf_section_type and elf_section_flags only when they are
	specified.

--- binutils/bfd/elf.c.type	2003-07-25 07:49:14.000000000 -0700
+++ binutils/bfd/elf.c	2003-07-25 10:55:04.000000000 -0700
@@ -2293,12 +2293,7 @@ _bfd_elf_new_section_hook (abfd, sec)
       sec->used_by_bfd = (PTR) sdata;
     }
 
-  if ((sec->flags & SEC_ALLOC) != 0
-      && (((sec->flags & (SEC_LOAD | SEC_HAS_CONTENTS)) == 0)
-	  || (sec->flags & SEC_NEVER_LOAD) != 0))
-    elf_section_type (sec) = SHT_NOBITS;
-  else
-    elf_section_type (sec) = SHT_PROGBITS;
+  elf_section_type (sec) = SHT_NULL;
   if (sec->name && _bfd_elf_get_sec_type_attr (abfd, sec->name,
 					       &type, &attr))
     {
@@ -2544,14 +2539,29 @@ elf_fake_sections (abfd, asect, failedpt
   this_hdr->bfd_section = asect;
   this_hdr->contents = NULL;
 
+  /* If the section type is unspecified, we set it based on
+     asect->flags.  */
+  if (this_hdr->sh_type == SHT_NULL)
+    {
+      if ((asect->flags & SEC_ALLOC) != 0
+	  && (((asect->flags & (SEC_LOAD | SEC_HAS_CONTENTS)) == 0)
+	      || (asect->flags & SEC_NEVER_LOAD) != 0))
+	this_hdr->sh_type = SHT_NOBITS;
+      else
+	this_hdr->sh_type = SHT_PROGBITS;
+    }
+
   switch (this_hdr->sh_type)
     {
     default:
+#if 0
+      /* FIXME: How to handle processor specific sections?  */
       (*_bfd_error_handler)
        (_("%s: Section `%s' has unknown type 0x%0x"),
 	bfd_get_filename (asect->owner), asect->name,
 	this_hdr->sh_type);
       abort ();
+#endif
       break;
 
     case SHT_STRTAB:
--- binutils/gas/config/obj-elf.c.type	2003-07-25 09:37:41.000000000 -0700
+++ binutils/gas/config/obj-elf.c	2003-07-25 09:52:59.000000000 -0700
@@ -683,8 +683,10 @@ obj_elf_change_section (name, type, attr
       attr |= def_attr;
     }
 
-  elf_section_type (sec) = type;
-  elf_section_flags (sec) = attr;
+  if (type != SHT_NULL)
+    elf_section_type (sec) = type;
+  if (attr != 0)
+    elf_section_flags (sec) = attr;
 
   /* Convert ELF type and flags to BFD flags.  */
   flags = (SEC_RELOC

  reply	other threads:[~2003-07-25 17:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-14 19:14 RFC: " H. J. Lu
2003-06-19 19:17 ` Andreas Schwab
     [not found] ` <m3y901rluw.fsf@redhat.com>
2003-07-25  1:36   ` PATCH: " H. J. Lu
2003-07-25  4:48     ` Alan Modra
2003-07-25 14:39       ` H. J. Lu
2003-07-25 12:29     ` Nick Clifton
2003-07-25 14:38       ` H. J. Lu
2003-07-25 16:10         ` H. J. Lu
2003-07-25 17:43           ` H. J. Lu
2003-07-25 17:59             ` H. J. Lu [this message]
2003-07-26  0:09               ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030725175940.GA940@lucon.org \
    --to=hjl@lucon.org \
    --cc=binutils@sources.redhat.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).