This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Please comment: A patch for elf32-i386.c
- To: fnf at be dot com, alan at linuxcare dot com dot au, binutils at sourceware dot cygnus dot com
- Subject: Please comment: A patch for elf32-i386.c
- From: "H . J . Lu" <hjl at valinux dot com>
- Date: Thu, 8 Feb 2001 17:36:35 -0800
- Cc: ctate at be dot com, dance at be dot com
This is a very unusal case. We are building a DSO from a non-PIC code
with weak definitions, linking against a DSO with strong definitions.
When elf_i386_check_relocs sees a weak definition in non-PIC code,
(h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) != 0
So no relocation entry is allocated. But later, elf_i386_relocate_section
finds out it has been changed to
(h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) == 0
due to a strong definition in DSO. Now we have more relocation entries
than we have allocated. This patch fixes the ld core dump. But I don't
know how to reclaim those entries if it is not the case. Alan, how can
I use elf_i386_discard_copies to do that? Why is there
if (h != NULL
&& ELF32_R_TYPE (rel->r_info) == R_386_PC32)
for using the pcrel_relocs_copied field? Can I change it to
if (h != NULL)
Thanks.
---
2001-02-08 H.J. Lu <hjl@gnu.org>
* elf32-i386.c (elf_i386_check_relocs): Handle building DSO
with weak definitions, -Bsymbolic and non-PIC code.
Index: elf32-i386.c
===================================================================
RCS file: /work/cvs/gnu/binutils/bfd/elf32-i386.c,v
retrieving revision 1.20
diff -u -p -r1.20 elf32-i386.c
--- elf32-i386.c 2001/01/23 20:11:11 1.20
+++ elf32-i386.c 2001/02/09 01:25:32
@@ -647,12 +647,18 @@ elf_i386_check_relocs (abfd, info, sec,
possibility below by storing information in the
pcrel_relocs_copied field of the hash table entry.
A similar situation occurs when creating shared libraries
- and symbol visibility changes render the symbol local. */
+ and symbol visibility changes render the symbol local.
+
+ We have to handle the case where we have a weak definition
+ which will be overridden later by a non-weak dynamic
+ definition. FIXME: We have to prepare to reclaim the unused
+ relocation entries if it is not the case. */
if (info->shared
&& (sec->flags & SEC_ALLOC) != 0
&& (ELF32_R_TYPE (rel->r_info) != R_386_PC32
|| (h != NULL
&& (! info->symbolic
+ || h->root.type == bfd_link_hash_defweak
|| (h->elf_link_hash_flags
& ELF_LINK_HASH_DEF_REGULAR) == 0))))
{