public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: binutils@sources.redhat.com
Cc: Richard Earnshaw <rearnsha@gcc.gnu.org>
Subject: Re: [patch] SymbianOS Arm executables
Date: Thu, 10 Feb 2005 17:29:00 -0000	[thread overview]
Message-ID: <200502101545.29671.paul@codesourcery.com> (raw)
In-Reply-To: <1108032923.4376.28.camel@pc960.cambridge.arm.com>

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

On Thursday 10 February 2005 10:55, Richard Earnshaw wrote:
> I'm uncomfortable about the way globals->symbian_p is getting scattered
> throughout the entire linking process.  I think we really need to try
> and distill that variable into the effects it has on linking (this would
> then make porting the linker to platforms with similar properties much
> less painful).
>
> In this case you've already identified the abstract property: the
> executable is relocated at link time.  Most of your used of ->symbian_p
> should therefore be ->exec_reloc_p.  There should then be exactly one
> place where symbian_p is tested, and that is then used to set the
> exec_reloc_p property.

Modified patch attached. No functional changes.

Retested on i686-linux, arm-none-elf and arm-none-symbianelf.
Ok?

Paul

2005-02-10  Paul Brook  <paul@codesourcery.com>

 * elf-bfd.h (struct elf_link_hash_table): Add exec_reloc_p.
 * elf.c (_bfd_elf_link_hash_table_init): Initialize it.
 * elflink.c (bfd_elf_link_record_dynamic_symbol): Create local dynamic
 symbols in relocatable executables.
 (bfd_elf_record_link_assignment): Create dynamic section symbols in
 relocatable executables.
 (_bfd_elf_link_renumber_dynsyms): Ditto.
 (bfd_elf_final_link): Ditto.
 * elf32-arm.c (elf32_arm_final_link_relocate): Copy absolute
 relocations into relocatable executables.
 (elf32_arm_check_relocs): Crate dynamic sections for relocatale
 executables.  Also copy absolute relocations.
 (elf32_arm_adjust_dynamic_symbol): Don't create copy relocations
 in relocatable executables.
 (allocate_dynrelocs): Copy relocations for relocatable executables.
 Output dynamic symbols for symbols defined in linker scripts.

[-- Attachment #2: patch.symbian_exec --]
[-- Type: text/x-diff, Size: 7376 bytes --]

Index: bfd/elf-bfd.h
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elf-bfd.h,v
retrieving revision 1.171
diff -u -p -r1.171 elf-bfd.h
--- bfd/elf-bfd.h	6 Feb 2005 23:21:44 -0000	1.171
+++ bfd/elf-bfd.h	10 Feb 2005 14:57:52 -0000
@@ -398,6 +398,10 @@ struct elf_link_hash_table
 
   /* A linked list of BFD's loaded in the link.  */
   struct elf_link_loaded_list *loaded;
+
+  /* True if This target has relocatable executables, so needs dynamic
+     section symbols.  */
+  bfd_boolean exec_reloc_p;
 };
 
 /* Look up an entry in an ELF linker hash table.  */
Index: bfd/elf.c
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elf.c,v
retrieving revision 1.264
diff -u -p -r1.264 elf.c
--- bfd/elf.c	6 Feb 2005 23:21:44 -0000	1.264
+++ bfd/elf.c	10 Feb 2005 15:11:21 -0000
@@ -1496,6 +1496,7 @@ _bfd_elf_link_hash_table_init
   table->tls_sec = NULL;
   table->tls_size = 0;
   table->loaded = NULL;
+  table->exec_reloc_p = FALSE;
 
   ret = _bfd_link_hash_table_init (&table->root, abfd, newfunc);
   table->root.type = bfd_link_elf_hash_table;
Index: bfd/elf32-arm.c
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elf32-arm.c,v
retrieving revision 1.21
diff -u -p -r1.21 elf32-arm.c
--- bfd/elf32-arm.c	10 Feb 2005 14:14:25 -0000	1.21
+++ bfd/elf32-arm.c	10 Feb 2005 14:56:05 -0000
@@ -2352,7 +2352,7 @@ elf32_arm_final_link_relocate (reloc_how
 
       /* When generating a shared object, these relocations are copied
 	 into the output file to be resolved at run time.  */
-      if (info->shared
+      if ((info->shared || globals->root.exec_reloc_p)
 	  && (input_section->flags & SEC_ALLOC)
 	  && (r_type != R_ARM_REL32
 	      || !SYMBOL_CALLS_LOCAL (info, h))
@@ -3986,6 +3986,14 @@ elf32_arm_check_relocs (bfd *abfd, struc
   htab = elf32_arm_hash_table (info);
   sreloc = NULL;
 
+  /* Create dynamic sections for relocatable executables so that we can
+     copy relocations.  */
+  if (htab->root.exec_reloc_p && ! htab->root.dynamic_sections_created)
+    {
+      if (! _bfd_elf_link_create_dynamic_sections (abfd, info))
+	return FALSE;
+    }
+
   dynobj = elf_hash_table (info)->dynobj;
   local_got_offsets = elf_local_got_offsets (abfd);
 
@@ -4106,11 +4114,11 @@ elf32_arm_check_relocs (bfd *abfd, struc
 		  eh->plt_thumb_refcount += 1;
 	      }
 
-	    /* If we are creating a shared library, and this is a reloc
-               against a global symbol, or a non PC relative reloc
-               against a local symbol, then we need to copy the reloc
-               into the shared library.  However, if we are linking with
-               -Bsymbolic, we do not need to copy a reloc against a
+	    /* If we are creating a shared library or relocatable executable,
+	       and this is a reloc against a global symbol, or a non PC
+	       relative reloc against a local symbol, then we need to copy
+	       the reloc into the shared library.  However, if we are linking
+	       with -Bsymbolic, we do not need to copy a reloc against a
                global symbol which is defined in an object we are
                including in the link (i.e., DEF_REGULAR is set).  At
                this point we have not seen all the input files, so it is
@@ -4118,7 +4126,7 @@ elf32_arm_check_relocs (bfd *abfd, struc
                later (it is never cleared).  We account for that
                possibility below by storing information in the
                relocs_copied field of the hash table entry.  */
-	    if (info->shared
+	    if ((info->shared || htab->root.exec_reloc_p)
 		&& (sec->flags & SEC_ALLOC) != 0
 		&& ((r_type != R_ARM_PC24
 		     && r_type != R_ARM_PLT32
@@ -4378,7 +4386,9 @@ elf32_arm_adjust_dynamic_symbol (struct 
   asection * s;
   unsigned int power_of_two;
   struct elf32_arm_link_hash_entry * eh;
+  struct elf32_arm_link_hash_table *globals;
 
+  globals = elf32_arm_hash_table (info);
   dynobj = elf_hash_table (info)->dynobj;
 
   /* Make sure we know what is going on here.  */
@@ -4443,8 +4453,10 @@ elf32_arm_adjust_dynamic_symbol (struct 
   /* If we are creating a shared library, we must presume that the
      only references to the symbol are via the global offset table.
      For such cases we need not do anything here; the relocations will
-     be handled correctly by relocate_section.  */
-  if (info->shared)
+     be handled correctly by relocate_section.  Relocatable executables
+     can reference data in shared objects directly, so we don't need to
+     do anything here.  */
+  if (info->shared || globals->root.exec_reloc_p)
     return TRUE;
 
   /* We must allocate the symbol in our .dynbss section, which will
@@ -4637,13 +4649,23 @@ allocate_dynrelocs (struct elf_link_hash
      space for pc-relative relocs that have become local due to symbol
      visibility changes.  */
 
-  if (info->shared)
+  if (info->shared || htab->root.exec_reloc_p)
     {
       /* Discard relocs on undefined weak syms with non-default
          visibility.  */
       if (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
 	  && h->root.type == bfd_link_hash_undefweak)
 	eh->relocs_copied = NULL;
+      else if (htab->root.exec_reloc_p && h->dynindx == -1
+	       && h->root.type == bfd_link_hash_new)
+	{
+	  /* Output absolute symbols so that we can create relocations
+	     against them.  For normal symbols we output a relocation
+	     against the section that contains them.  */
+	  if (! bfd_elf_link_record_dynamic_symbol (info, h))
+	    return FALSE;
+	}
+
     }
   else
     {
@@ -5846,6 +5868,7 @@ elf32_arm_symbian_link_hash_table_create
       /* The PLT entries are each three instructions.  */
       htab->plt_entry_size = 4 * NUM_ELEM (elf32_arm_symbian_plt_entry);
       htab->symbian_p = 1;
+      htab->root.exec_reloc_p = 1;
     }
   return ret;
 }     
Index: bfd/elflink.c
===================================================================
RCS file: /var/cvsroot/src-cvs/src/bfd/elflink.c,v
retrieving revision 1.133
diff -u -p -r1.133 elflink.c
--- bfd/elflink.c	10 Feb 2005 14:09:40 -0000	1.133
+++ bfd/elflink.c	10 Feb 2005 15:10:45 -0000
@@ -386,7 +386,8 @@ bfd_elf_link_record_dynamic_symbol (stru
 	      && h->root.type != bfd_link_hash_undefweak)
 	    {
 	      h->forced_local = 1;
-	      return TRUE;
+	      if (!elf_hash_table (info)->exec_reloc_p)
+		return TRUE;
 	    }
 
 	default:
@@ -494,7 +495,8 @@ bfd_elf_record_link_assignment (bfd *out
 
   if ((h->def_dynamic
        || h->ref_dynamic
-       || info->shared)
+       || info->shared
+       || (info->executable && elf_hash_table (info)->exec_reloc_p))
       && h->dynindx == -1)
     {
       if (! bfd_elf_link_record_dynamic_symbol (info, h))
@@ -710,7 +712,7 @@ _bfd_elf_link_renumber_dynsyms (bfd *out
 {
   unsigned long dynsymcount = 0;
 
-  if (info->shared)
+  if (info->shared || elf_hash_table (info)->exec_reloc_p)
     {
       const struct elf_backend_data *bed = get_elf_backend_data (output_bfd);
       asection *p;
@@ -8167,7 +8169,7 @@ bfd_elf_final_link (bfd *abfd, struct bf
       long last_local = 0;
 
       /* Write out the section symbols for the output sections.  */
-      if (info->shared)
+      if (info->shared || elf_hash_table (info)->exec_reloc_p)
 	{
 	  asection *s;
 

  reply	other threads:[~2005-02-10 15:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-09 23:38 Paul Brook
2005-02-10 15:58 ` Richard Earnshaw
2005-02-10 17:29   ` Paul Brook [this message]
2005-02-10 19:54     ` Richard Earnshaw
2005-02-11 15:15 Nick Clifton

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=200502101545.29671.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=binutils@sources.redhat.com \
    --cc=rearnsha@gcc.gnu.org \
    /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).