Index: elf32-m68k.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-m68k.c,v
retrieving revision 1.61.6.1
diff -u -a -p -a -u -p -r1.61.6.1 elf32-m68k.c
--- elf32-m68k.c 8 Apr 2004 12:41:42 -0000 1.61.6.1
+++ elf32-m68k.c 25 Nov 2004 00:15:53 -0000
@@ -940,9 +940,10 @@ elf_m68k_adjust_dynamic_symbol (info, h)
if (h->type == STT_FUNC
|| (h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT) != 0)
{
- if (! info->shared
- && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_DYNAMIC) == 0
- && (h->elf_link_hash_flags & ELF_LINK_HASH_REF_DYNAMIC) == 0
+ if ((h->plt.refcount <= 0
+ || SYMBOL_CALLS_LOCAL (info, h)
+ || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
+ && h->root.type == bfd_link_hash_undefweak))
/* We must always create the plt entry if it was referenced
by a PLTxxO relocation. In this case we already recorded
it as a dynamic symbol. */
@@ -950,19 +951,11 @@ elf_m68k_adjust_dynamic_symbol (info, h)
{
/* This case can occur if we saw a PLTxx reloc in an input
file, but the symbol was never referred to by a dynamic
- object. In such a case, we don't actually need to build
- a procedure linkage table, and we can just do a PCxx
- reloc instead. */
- BFD_ASSERT ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT) != 0);
+ object, or if all references were garbage collected. In
+ such a case, we don't actually need to build a procedure
+ linkage table, and we can just do a PCxx reloc instead. */
h->plt.offset = (bfd_vma) -1;
- return TRUE;
- }
-
- /* GC may have rendered this entry unused. */
- if (h->plt.refcount <= 0)
- {
h->elf_link_hash_flags &= ~ELF_LINK_HASH_NEEDS_PLT;
- h->plt.offset = (bfd_vma) -1;
return TRUE;
}
Andreas.
--
Andreas Schwab, SuSE Labs, <email address hidden>
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Matthias Klose <email address hidden> writes:
> Andreas Schwab writes: sources. redhat. com/cgi- bin/cvsweb. cgi/src/ bfd/elf32- m68k.c. diff?cvsroot= src&r1= 1.70&r2= 1.71
>> This is a bug in binutils 2.15 that's already fixed in CVS HEAD.
>
> Andreas, please could you confirm this patch from upstream:
>
> http://
>
This works for me:
Index: elf32-m68k.c ======= ======= ======= ======= ======= ======= ======= ======= ==== src/bfd/ elf32-m68k. c,v adjust_ dynamic_ symbol (info, h) link_hash_ flags & ELF_LINK_ HASH_NEEDS_ PLT) != 0) link_hash_ flags & ELF_LINK_ HASH_DEF_ DYNAMIC) == 0 link_hash_ flags & ELF_LINK_ HASH_REF_ DYNAMIC) == 0 hash_undefweak) ) adjust_ dynamic_ symbol (info, h) link_hash_ flags & ELF_LINK_ HASH_NEEDS_ PLT) != 0); elf_link_ hash_flags &= ~ELF_LINK_ HASH_NEEDS_ PLT;
=======
RCS file: /cvs/src/
retrieving revision 1.61.6.1
diff -u -a -p -a -u -p -r1.61.6.1 elf32-m68k.c
--- elf32-m68k.c 8 Apr 2004 12:41:42 -0000 1.61.6.1
+++ elf32-m68k.c 25 Nov 2004 00:15:53 -0000
@@ -940,9 +940,10 @@ elf_m68k_
if (h->type == STT_FUNC
|| (h->elf_
{
- if (! info->shared
- && (h->elf_
- && (h->elf_
+ if ((h->plt.refcount <= 0
+ || SYMBOL_CALLS_LOCAL (info, h)
+ || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
+ && h->root.type == bfd_link_
/* We must always create the plt entry if it was referenced
by a PLTxxO relocation. In this case we already recorded
it as a dynamic symbol. */
@@ -950,19 +951,11 @@ elf_m68k_
{
/* This case can occur if we saw a PLTxx reloc in an input
file, but the symbol was never referred to by a dynamic
- object. In such a case, we don't actually need to build
- a procedure linkage table, and we can just do a PCxx
- reloc instead. */
- BFD_ASSERT ((h->elf_
+ object, or if all references were garbage collected. In
+ such a case, we don't actually need to build a procedure
+ linkage table, and we can just do a PCxx reloc instead. */
h->plt.offset = (bfd_vma) -1;
- return TRUE;
- }
-
- /* GC may have rendered this entry unused. */
- if (h->plt.refcount <= 0)
- {
h->
- h->plt.offset = (bfd_vma) -1;
return TRUE;
}
Andreas.
--
Andreas Schwab, SuSE Labs, <email address hidden>
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."