public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H . J . Lu" <hjl@lucon.org>
To: Nick Clifton <nickc@cambridge.redhat.com>
Cc: binutils@sources.redhat.com, Ian Lance Taylor <ian@zembu.com>
Subject: Re: elf_link_hash_entry vs generic_link_hash_entry
Date: Thu, 23 Aug 2001 12:10:00 -0000	[thread overview]
Message-ID: <20010823120958.A18304@lucon.org> (raw)
In-Reply-To: <20010823113656.A17692@lucon.org>

On Thu, Aug 23, 2001 at 11:36:56AM -0700, H . J . Lu wrote:
> On Thu, Aug 23, 2001 at 09:21:40AM -0700, H . J . Lu wrote:
> > On Wed, Aug 22, 2001 at 08:41:11AM +0100, Nick Clifton wrote:
> > > 
> > >    3. Go back to the old situation where elf ports that do not provide
> > >       their own relocation backends use the generic linker hash table
> > >       entry structure, but add code to the other elf routines to
> > >       detect this and fail before they try to access fields in the
> > >       hash structure that are not there.
> > > 
> > 
> > I'd like this one. How about we turn elf_hash_table into something
> > specific to each backend? For those targets which don't use
> > _bfd_elf_link_hash_table_create, it will return NULL or a fatal
> > bfd error.
> > 
> > 
> 
> Here is a patch. Ian, as you mentioned, linking directly to S-records
> no longer works. I got
> 
> /export/build/gnu/binutils/build-full-i686-linux/ld/ld-new  -o tmpdir/sr2.sr -T text 0x1000 --oformat srec tmpdir/sr1.o tmpdir/sr2.o
> child killed: segmentation violation
> FAIL: S-records
> /export/build/gnu/binutils/build-full-i686-linux/ld/ld-new  -o tmpdir/sr2.sr -T text 0x1000 --oformat srec tmpdir/sr3.o
> child killed: segmentation violation
> FAIL: S-records with constructors
> 
> How should we fix it?
> 

How about this patch?

H.J.
----
2001-08-23  H.J. Lu  <hjl@gnu.org>

        * elflink.h (elf_link_add_object_symbols): Don't merge section
        nor add the file to the loaded list if the linker hash table
        is not an an ELF linker hash table.

Index: elflink.h
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.70
diff -u -p -r1.70 elflink.h
--- elflink.h	2001/08/23 17:02:20	1.70
+++ elflink.h	2001/08/23 19:07:05
@@ -1068,7 +1068,10 @@ elf_link_add_object_symbols (abfd, info)
   Elf_External_Sym *esymend;
   struct elf_backend_data *bed;
   boolean dt_needed;
+  struct elf_link_hash_table *hash_table;
 
+  hash_table = elf_hash_table (info);
+
   bed = get_elf_backend_data (abfd);
   add_symbol_hook = bed->elf_add_symbol_hook;
   collect = bed->collect;
@@ -2330,33 +2333,32 @@ elf_link_add_object_symbols (abfd, info)
 	}
     }
 
-  if (! info->relocateable && ! dynamic)
+  if (hash_table && ! info->relocateable && ! dynamic)
     {
       asection *s;
 
       for (s = abfd->sections; s != NULL; s = s->next)
 	if ((s->flags & SEC_MERGE)
-	    && ! _bfd_merge_section (abfd,
-				     &elf_hash_table (info)->merge_info,
-				     s, &elf_section_data (s)->merge_info))
+	    && ! _bfd_merge_section (abfd, &hash_table->merge_info, s,
+				     &elf_section_data (s)->merge_info))
 	  goto error_return;
     }
+
+  if (hash_table)
+    {
+      /* We add this to the loaded list.  */
+      struct elf_link_loaded_list *n, **pn;
 
-  {
-    /* We add this to the loaded list.  */
-    struct elf_link_loaded_list *n, **pn;
-
-    n = ((struct elf_link_loaded_list *)
-	 bfd_alloc (abfd, sizeof (struct elf_link_loaded_list)));
-    if (n == NULL)
-      goto error_return;
-    n->next = NULL;
-    n->abfd = abfd;
-    for (pn = &elf_hash_table (info)->loaded; *pn != NULL;
-	 pn = &(*pn)->next)
-      ;
-    *pn = n;
-  }
+      n = ((struct elf_link_loaded_list *)
+	   bfd_alloc (abfd, sizeof (struct elf_link_loaded_list)));
+      if (n == NULL)
+	goto error_return;
+      n->next = NULL;
+      n->abfd = abfd;
+      for (pn = &hash_table->loaded; *pn != NULL; pn = &(*pn)->next)
+	;
+      *pn = n;
+    }
 
   return true;
 

  reply	other threads:[~2001-08-23 12:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <si66bh2zdl.fsf@daffy.airs.com>
2001-08-22  0:44 ` Nick Clifton
2001-08-22  1:06   ` Thiemo Seufer
2001-08-22  7:02     ` Ian Lance Taylor
2001-08-23  9:22   ` H . J . Lu
2001-08-23 11:36     ` H . J . Lu
2001-08-23 12:10       ` H . J . Lu [this message]
2001-08-24  9:35         ` Nick Clifton
2001-08-24  9:54           ` H . J . Lu
2001-08-24 10:02           ` H . J . Lu
2001-08-24  9:18       ` Nick Clifton
2001-08-24  9:22         ` H . J . Lu
2001-08-28 15:53       ` Richard Henderson

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=20010823120958.A18304@lucon.org \
    --to=hjl@lucon.org \
    --cc=binutils@sources.redhat.com \
    --cc=ian@zembu.com \
    --cc=nickc@cambridge.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).