From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31591 invoked by alias); 10 Feb 2005 15:46:05 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 30296 invoked from network); 10 Feb 2005 15:45:32 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 10 Feb 2005 15:45:32 -0000 Received: (qmail 26409 invoked from network); 10 Feb 2005 15:45:31 -0000 Received: from localhost (HELO wren.home) (paul@127.0.0.1) by mail.codesourcery.com with SMTP; 10 Feb 2005 15:45:31 -0000 From: Paul Brook Organization: CodeSourcery To: binutils@sources.redhat.com Subject: Re: [patch] SymbianOS Arm executables Date: Thu, 10 Feb 2005 17:29:00 -0000 User-Agent: KMail/1.7.2 Cc: Richard Earnshaw References: <200502092035.43426.paul@codesourcery.com> <1108032923.4376.28.camel@pc960.cambridge.arm.com> In-Reply-To: <1108032923.4376.28.camel@pc960.cambridge.arm.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ZG4CC6/7HI0gpmy" Message-Id: <200502101545.29671.paul@codesourcery.com> X-SW-Source: 2005-02/txt/msg00205.txt.bz2 --Boundary-00=_ZG4CC6/7HI0gpmy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 1690 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 * 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. --Boundary-00=_ZG4CC6/7HI0gpmy Content-Type: text/x-diff; charset="iso-8859-1"; name="patch.symbian_exec" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch.symbian_exec" Content-length: 7376 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; --Boundary-00=_ZG4CC6/7HI0gpmy--